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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211005093137.GQ3959@techsingularity.net>
Date:   Tue, 5 Oct 2021 10:31:37 +0100
From:   Mel Gorman <mgorman@...hsingularity.net>
To:     Mike Galbraith <efault@....de>
Cc:     Barry Song <21cnbao@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Valentin Schneider <valentin.schneider@....com>,
        Aubrey Li <aubrey.li@...ux.intel.com>,
        Barry Song <song.bao.hua@...ilicon.com>,
        Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>
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