Re: wakeup_affine_weight() is b0rked - was Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running

[Mel Gorman]

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