Messages in this thread | | | Date | Tue, 5 Oct 2021 10:31:37 +0100 | From | Mel Gorman <> | Subject | Re: wakeup_affine_weight() is b0rked - was Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running |
| |
On Tue, Oct 05, 2021 at 10:42:07AM +0200, Mike Galbraith wrote: > 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. >
Thanks Mike.
If you write a formal patch with a Signed-off-by, I'll use it as a baseline for the wakegran work or submit it directly. That way, I'll get any LKP reports, user regression reports on lkml, any regression reports via openSUSE etc and deal with them.
Based on the results I have so far, I would not be twiddling it further but that might change when a full range of machines have completed all of their tests. Ideally, I would do some tracing to confirm that maximum runqueue depth is really reduced by the path.
-- Mel Gorman SUSE Labs
| |