All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: Vincent Guittot <vincent.guittot@linaro.org>,
	Mel Gorman <mgorman@techsingularity.net>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.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: [PATCH 1/2] sched/fair: Couple wakee flips with heavy wakers
Date: Sat, 30 Oct 2021 06:12:17 +0200	[thread overview]
Message-ID: <91cb83b8e05076bd6650e3bfcda00feb890b911a.camel@gmx.de> (raw)
In-Reply-To: <ab98b05314846102baec5cbb46893675f4ea5cfb.camel@gmx.de>

On Sat, 2021-10-30 at 05:11 +0200, Mike Galbraith wrote:
>
> I profiled it with a perf that sums delay (local mod I find useful)...

Here are those numbers for completeness.  As you can see, patchlet was
fairly meaningless to the desktop load.  In fact, even though the wake
affine logic essentially favors the compute load over the heavily
threaded but light desktop load, I noticed zero difference with or
without that being allowed, nor did perf record any noteworthy latency
events, just more wait as load was kinda sorta de-treaded by being
stacked up.

box = i7-4790 quad+smt
desktop vs massive_intr 8 9999 (8 x 8ms run/1ms sleep, for 9999 secs.. effectively forever)
perf sched record -a -- su mikeg -c 'firefox https://www.youtube.com/watch?v=aqz-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%


  reply	other threads:[~2021-10-30  4:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-28  9:48 [PATCH v4 0/2] Reduce stacking and overscheduling Mel Gorman
2021-10-28  9:48 ` [PATCH 1/2] sched/fair: Couple wakee flips with heavy wakers Mel Gorman
2021-10-28 16:19   ` Tao Zhou
2021-10-29  8:42     ` Mel Gorman
2021-11-10  9:53       ` Tao Zhou
2021-11-10 15:40         ` Mike Galbraith
2021-10-29 15:17   ` Vincent Guittot
2021-10-30  3:11     ` Mike Galbraith
2021-10-30  4:12       ` Mike Galbraith [this message]
2021-11-01  8:56     ` Mel Gorman
2021-10-28  9:48 ` [PATCH 2/2] sched/fair: Increase wakeup_gran if current task has not executed the minimum granularity Mel Gorman
2021-10-29 16:07   ` Vincent Guittot
  -- strict thread matches above, loose matches on Subject: below --
2021-10-21 14:56 [PATCH 0/2] Reduce stacking and overscheduling Mel Gorman
2021-10-21 14:56 ` [PATCH 1/2] sched/fair: Couple wakee flips with heavy wakers Mel Gorman
2021-10-22 10:26   ` Mike Galbraith
2021-10-22 11:05     ` Mel Gorman
2021-10-22 12:00       ` Mike Galbraith
2021-10-25  6:35       ` Mike Galbraith
2021-10-26  8:18         ` Mel Gorman
2021-10-26 10:15           ` Mike Galbraith
2021-10-26 10:41             ` Mike Galbraith
2021-10-26 11:57               ` Mel Gorman
2021-10-26 12:13                 ` Mike Galbraith
2021-10-27  2:09                   ` Mike Galbraith
2021-10-27  9:00                     ` Mel Gorman
2021-10-27 10:18                       ` Mike Galbraith
2021-11-09 11:56   ` Peter Zijlstra
2021-11-09 12:55     ` Mike Galbraith

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=91cb83b8e05076bd6650e3bfcda00feb890b911a.camel@gmx.de \
    --to=efault@gmx.de \
    --cc=Valentin.Schneider@arm.com \
    --cc=aubrey.li@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=song.bao.hua@hisilicon.com \
    --cc=srikar@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.