2015-06-11 20:33:46

by Josef Bacik

[permalink] [raw]
Subject: 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


2015-06-12 03:42:23

by Rik van Riel

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

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 <[email protected]>

--
All rights reversed