Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1163586 > unrolled thread

Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for  BALANCE_WAKE Josef Bacik <jbacik@fb.com> - 2015-06-11 22:40 +0200
    Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for  BALANCE_WAKE Rik van Riel <riel@redhat.com> - 2015-06-12 05:50 +0200

#1163586 — Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE

On 05/28/2015 07:05 AM, Peter Zijlstra wrote:
>
> So maybe you want something like the below; that cures the thing Morten
> raised, and we continue looking for sd, even after we found affine_sd.
>
> It also avoids the pointless idle_cpu() check Mike raised by making
> select_idle_sibling() return -1 if it doesn't find anything.
>
> Then it continues doing the full balance IFF sd was set, which is keyed
> off of sd->flags.
>
> And note (as Mike already said), BALANCE_WAKE does _NOT_ look for idle
> CPUs, it looks for the least loaded CPU. And its damn expensive.
>
>
> Rewriting this entire thing is somewhere on the todo list :/
>

Ugh I'm sorry, I've been running tests trying to get the numbers to look 
good when I noticed I was getting some inconsistencies in my results. 
Turns out I never actually tested your patch just plain, I had been 
testing it with BALANCE_WAKE, because I was under the assumption that 
was what was best for our workload.  Since then I had fixed all of our 
scripts and such and noticed that it actually super duper sucks for us. 
  So testing with this original patch everything is significantly better 
(this is with the default SD flags set, no changes at all).

So now that I've wasted a good bit of my time and everybody elses, can 
we go about pushing this patch upstream?  If you are happy with it the 
way it is I'll go ahead and pull it into our kernels and just watch to 
make sure it ends upstream at some point.  Thanks,

Josef

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1163748

On 06/11/2015 04:33 PM, Josef Bacik wrote:

> Ugh I'm sorry, I've been running tests trying to get the numbers to look
> good when I noticed I was getting some inconsistencies in my results.
> Turns out I never actually tested your patch just plain, I had been
> testing it with BALANCE_WAKE, because I was under the assumption that
> was what was best for our workload.  Since then I had fixed all of our
> scripts and such and noticed that it actually super duper sucks for us.
>  So testing with this original patch everything is significantly better
> (this is with the default SD flags set, no changes at all).
> 
> So now that I've wasted a good bit of my time and everybody elses, can
> we go about pushing this patch upstream?  If you are happy with it the
> way it is I'll go ahead and pull it into our kernels and just watch to
> make sure it ends upstream at some point.  Thanks,

FWIW, Jirka has run some tests with the patch as well,
and seen significant performance improvements on
various tests, on various systems.

Merging the patch makes perfect sense to me.

Acked-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web