From: Mel Gorman <mgorman@techsingularity.net>
To: Mike Galbraith <efault@gmx.de>
Cc: Barry Song <21cnbao@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Valentin Schneider <valentin.schneider@arm.com>,
Aubrey Li <aubrey.li@linux.intel.com>,
Barry Song <song.bao.hua@hisilicon.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: wakeup_affine_weight() is b0rked - was Re: [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running
Date: Tue, 5 Oct 2021 10:31:37 +0100 [thread overview]
Message-ID: <20211005093137.GQ3959@techsingularity.net> (raw)
In-Reply-To: <ba1195a9843add64b38fce9ceb186c0c21ef5783.camel@gmx.de>
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
next prev parent reply other threads:[~2021-10-05 9:31 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 14:26 [PATCH 0/2] Scale wakeup granularity relative to nr_running Mel Gorman
2021-09-20 14:26 ` [PATCH 1/2] sched/fair: Remove redundant lookup of rq in check_preempt_wakeup Mel Gorman
2021-09-21 7:21 ` Vincent Guittot
2021-09-21 7:53 ` Mel Gorman
2021-09-21 8:12 ` Vincent Guittot
2021-09-21 8:21 ` Peter Zijlstra
2021-09-21 10:03 ` Mel Gorman
2021-09-20 14:26 ` [PATCH 2/2] sched/fair: Scale wakeup granularity relative to nr_running Mel Gorman
2021-09-21 3:52 ` Mike Galbraith
2021-09-21 5:50 ` Mike Galbraith
2021-09-21 7:04 ` Mike Galbraith
2021-09-21 10:36 ` Mel Gorman
2021-09-21 12:32 ` Mike Galbraith
2021-09-21 14:03 ` Mel Gorman
2021-10-05 9:24 ` Peter Zijlstra
2021-09-22 5:22 ` Mike Galbraith
2021-09-22 13:20 ` Mel Gorman
2021-09-22 14:04 ` Mike Galbraith
2021-09-22 14:15 ` Vincent Guittot
2021-09-22 15:04 ` Mel Gorman
2021-09-22 16:00 ` Vincent Guittot
2021-09-22 17:38 ` Mel Gorman
2021-09-22 18:22 ` Vincent Guittot
2021-09-22 18:57 ` Mel Gorman
2021-09-23 1:47 ` Mike Galbraith
2021-09-23 8:40 ` Vincent Guittot
2021-09-23 9:21 ` Mike Galbraith
2021-09-23 12:41 ` Vincent Guittot
2021-09-23 13:14 ` Mike Galbraith
2021-09-27 11:17 ` Mel Gorman
2021-09-27 14:17 ` Mike Galbraith
2021-10-04 8:05 ` Mel Gorman
2021-10-04 16:37 ` Vincent Guittot
2021-10-05 7:41 ` Mel Gorman
2021-09-27 14:19 ` Vincent Guittot
2021-09-27 15:02 ` Mel Gorman
2021-09-23 12:24 ` Phil Auld
2021-10-05 10:36 ` Peter Zijlstra
2021-10-05 14:12 ` Phil Auld
2021-10-05 14:32 ` Peter Zijlstra
2021-10-05 10:28 ` Peter Zijlstra
2021-10-05 10:23 ` Peter Zijlstra
2021-10-05 9:41 ` Peter Zijlstra
2021-09-22 15:05 ` Vincent Guittot
2021-10-05 9:32 ` Peter Zijlstra
2021-10-03 3:07 ` wakeup_affine_weight() is b0rked - was " Mike Galbraith
2021-10-03 7:34 ` Barry Song
2021-10-03 14:52 ` Mike Galbraith
2021-10-03 21:06 ` Barry Song
2021-10-04 1:49 ` Mike Galbraith
2021-10-04 4:34 ` Mike Galbraith
2021-10-04 9:06 ` Mike Galbraith
2021-10-05 7:47 ` Mel Gorman
2021-10-05 8:42 ` Mike Galbraith
2021-10-05 9:31 ` Mel Gorman [this message]
2021-10-06 6:46 ` Mike Galbraith
2021-10-08 5:06 ` Mike Galbraith
2021-09-21 8:03 ` Vincent Guittot
2021-09-21 10:45 ` Mel Gorman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211005093137.GQ3959@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=21cnbao@gmail.com \
--cc=aubrey.li@linux.intel.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=song.bao.hua@hisilicon.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=valentin.schneider@arm.com \
--cc=vincent.guittot@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).