lkml.org 
[lkml]   [2013]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] sched: wake-affine throttle
From
Date
On Fri, 2013-05-03 at 11:46 +0800, Michael Wang wrote: 
> On 04/10/2013 11:30 AM, Michael Wang wrote:
>
> Now long time has been passed since the first version, I'd like to
> do some summary about current states:
>
> On a 12 cpu box with tip 3.9.0-rc7, test show that:
>
> 1. remove wake-affine stuff cause regression on hackbench (could be 15%).
> 2. reserve wake-affine stuff cause regression on pgbench (could be 45%).
>
> And since neither remove or reserve is acceptable, this patch introduced a
> knob to throttle wake-affine stuff.
>
> By turning the knob, we could benefit both hackbench and pgbench, or sacrifice
> one to significantly benefit another.
>
> All similar workload which prefer or hate wake-affine behaviour could
> been cared.
>
> If this approach caused any concerns, please let me know ;-)

I wonder if throttling on failure is the way to go. Note the minimal
gain for pgbench with the default 1ms throttle interval. It's not very
effective out of the box for the load type it's targeted to help, and
people generally don't twiddle scheduler knobs. If you throttle on
success, you directly restrict migration frequency without that being
affected by what other tasks are doing. Seems that would be a bit more
effective.

(I still like the wakeup buddy thing, it's more effective because it
adds and uses knowledge, though without the knob, cache domain size.
Peter is right about the interrupt wakeups though, that could very
easily cause regressions, dirt simple throttle is much safer).

-Mike



\
 
 \ /
  Last update: 2013-05-03 07:41    [W:0.282 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site