Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <2fd273f7284c78b65927b2b2572a66985cee0199.camel@gmx.de>
Subject: Re: [PATCH 1/2] sched/fair: Couple wakee flips with heavy wakers
From:   Mike Galbraith <efault@gmx.de>
To:     Mel Gorman <mgorman@techsingularity.net>
Cc:     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>
Date:   Fri, 22 Oct 2021 14:00:38 +0200
In-Reply-To: <20211022110534.GJ3959@techsingularity.net>
References: <20211021145603.5313-1-mgorman@techsingularity.net>
         <20211021145603.5313-2-mgorman@techsingularity.net>
         <37d8c167df66a1ead16b699115548ca376494c0c.camel@gmx.de>
         <20211022110534.GJ3959@techsingularity.net>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.0 
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, 2021-10-22 at 12:05 +0100, Mel Gorman wrote:
> On Fri, Oct 22, 2021 at 12:26:08PM +0200, Mike Galbraith wrote:
>
> >
> > Hm.=C2=A0 If patchlet repeatably impacts buddy pairs one way or the ot=
her,
> > it should probably be tossed out the nearest window.
> >
>
> I don't see how buddy pairing would be impacted although there is likely
> differences in the degree tasks get preempted due to pulling tasks.

Hohum, numbers get to say whatever (weirdness) they want to I suppose.

btw, below are some desktop impact numbers I had collected.

box =3D i7-4790 quad+smt
desktop vs massive_intr 8 9999 (8 x 8ms run/1ms sleep, for 9999 secs.. eff=
ectively forever)
perf sched record -a -- su mikeg -c 'firefox https://www.youtube.com/watch=
?v=3Daqz-KE-bpKQ'& sleep 300 && killall perf firefox
                     runtime              runtime               sum delay =
     sum delay        sum delay       switches      desktop
patch/features       total          util  massive_intr   util   total     =
     massive_intr     desktop        total/massive  util
virgin/stock         2267347.921 ms 94.4% 1932675.152 ms 80.5%  158611.016=
 ms  133309.938 ms    25301.078 ms  594780/441157   13.9%
virgin/-wa_weight    2236871.408 ms 93.2% 1881464.401 ms 78.3%  255785.391=
 ms  243958.616 ms    11826.775 ms 1525470/1424083  14.8%
                          -1.34%    -1.2%                -2.2%            =
                        -13.474 s                   +0.9%
wake_wide/stock      2254335.961 ms 93.9% 1917834.157 ms 79.9%  164766.194=
 ms  141974.540 ms    22791.654 ms  720711/599064   14.0%

While patchlet mitigated the stacking somewhat, it wasn't meaningful to
my test load (BigBuckBunny for the 10001th time).  PELT clearly stacks
up the desktop pretty damn badly, but gets away with it.. in this case.

OTOH, killing stacking graveyard dead via NO_WA_WEIGHT would have
certainly dinged up cache quite a bit for the compute load had it been
something other than a synthetic CPU burner, so there's a brownie point
for PELT in the mix to go along with its stacking demerit.

Given there was zero perceptible difference, the only thing patchlet
really did was to give me a warm fuzzy knowing it was in there fighting
the good fight against obscene *looking* stacking (with potential).

	-Mike