Messages in this thread | | | Subject | Re: wakeup_affine_weight() is b0rked - was Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running | From | Mike Galbraith <> | Date | Tue, 05 Oct 2021 10:42:07 +0200 |
| |
On Tue, 2021-10-05 at 08:47 +0100, Mel Gorman wrote: > On Mon, Oct 04, 2021 at 11:06:30AM +0200, Mike Galbraith wrote: > > > > The mallet below convinced wake_wide() that X waking event threads is > > something it most definitely should care about. It's not perfect, can > > get caught with its pants down, because behavior changes a LOT, but I > > at least have to work at it a bit to stack tasks to the ceiling. > > > > With make -j8 running along with firefox with two tabs, one containing > > youtube's suggestions of stuff you probably don't want to watch, the > > other a running clip, if I have the idle tab in focus, and don't drive > > mouse around, flips decay enough for wake_wide() to lose interest, but > > just wiggle the mouse, and it starts waking wide. Focus on the running > > clip, and it continuously wakes wide. > > > > Hacky, but way better behavior.. at this particular testcase.. in this > > particular box.. at least once :) > > > > Only three machines managed to complete tests overnight. For most > workloads test, it was neutral or slight improvements. For > multi-kernbench__netperf-tcp-rr-multipair (kernel compile + > netperf-tcp-rr combined), there was little to no change. > > For the heavy overloaded cases (hackbench again), it was variable. Worst > improvement was a gain of 1-3%. Best improvement (single socket skylake > with 8 logical CPUs SMT enabled) was 1%-18% depending on the group > count.
I wrote up a changelog to remind future me why I bent it up, but I'm not going to submit it. I'll leave the twiddling to folks who can be more responsive to possible (spelled probable;) regression reports than I can be.
-Mike
| |