linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Vincent Guittot <vincent.guittot@linaro.org>
Cc: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, linux-kernel@vger.kernel.org,
	pauld@redhat.com, parth@linux.ibm.com,
	valentin.schneider@arm.com, hdanton@sina.com
Subject: Re: [PATCH v2 0/5] remove runnable_load_avg and improve group_classify
Date: Sat, 15 Feb 2020 21:58:24 +0000	[thread overview]
Message-ID: <20200215215823.GY3420@suse.de> (raw)
In-Reply-To: <20200214152729.6059-1-vincent.guittot@linaro.org>

On Fri, Feb 14, 2020 at 04:27:24PM +0100, Vincent Guittot wrote:
> This new version stays quite close to the previous one and should 
> replace without problems the previous one that part of Mel's patchset:
> https://lkml.org/lkml/2020/2/14/156
> 

As far as I can see, the differences are harmless and look sane. I do think
that an additional fix is mandatory as I see no reason why the regression
was fixed. As such, I'll release a v3 of the series that includes your
new patches with the minimal fix inserted where appropriate. I'll have
tests running over the rest of the weekend.

> Some hackbench results:
> 
> - small arm64 dual quad cores system
> hackbench -l (2560/#grp) -g #grp
> 
> grp    tip/sched/core         +patchset              improvement
> 1       1,327(+/-10,06 %)     1,247(+/-5,45 %)       5,97 %
> 4       1,250(+/- 2,55 %)     1,207(+/-2,12 %)       3,42 %
> 8       1,189(+/- 1,47 %)     1,179(+/-1,93 %)       0,90 %
> 16      1,221(+/- 3,25 %)     1,219(+/-2,44 %)       0,16 %						
> 
> - large arm64 2 nodes / 224 cores system
> hackbench -l (256000/#grp) -g #grp
> 
> grp    tip/sched/core         +patchset              improvement
> 1      14,197(+/- 2,73 %)     13,917(+/- 2,19 %)     1,98 %
> 4       6,817(+/- 1,27 %)      6,523(+/-11,96 %)     4,31 %
> 16      2,930(+/- 1,07 %)      2,911(+/- 1,08 %)     0,66 %
> 32      2,735(+/- 1,71 %)      2,725(+/- 1,53 %)     0,37 %
> 64      2,702(+/- 0,32 %)      2,717(+/- 1,07 %)    -0,53 %
> 128     3,533(+/-14,66 %)     3,123(+/-12,47 %)     11,59 %
> 256     3,918(+/-19,93 %)     3,390(+/- 5,93 %)     13,47 %
> 
> The significant improvement for 128 and 256 should be taken with care
> because of some instabilities over iterations without the patchset.
> 

For the most part I do not see similar results to this with hackbench with
one exception -- EPYC first generation. I don't have results for EPYC 2
yet but I'm curious if the machine you have has multiple L3 caches per
NUMA domain? Various Intel CPU generations show improvements but they're
not as dramatic.  Tests will tell me for sure but I have some confidence
that it'll look like

Small tracing patches -- no difference
Vincent Patches 1-2   -- regressions
Fix from Mel          -- small overall improvement on baseline
Vincent patches 3-5   -- small improvements mostly, sometimes big ones
                         on hackbench depending on the machine
Rest of Mel series    -- generally ok across machines and CPU generations

Even if the improvements are not dramatic, I think it'll be worth it to
have NUMA and CPU balancer using similarly sane logic and overall I find
the load balancer easier to understand with the new logic so yey!

-- 
Mel Gorman
SUSE Labs

  parent reply	other threads:[~2020-02-15 21:58 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14 15:27 [PATCH v2 0/5] remove runnable_load_avg and improve group_classify Vincent Guittot
2020-02-14 15:27 ` [PATCH v2 1/5] sched/fair: Reorder enqueue/dequeue_task_fair path Vincent Guittot
2020-02-18 12:37   ` Dietmar Eggemann
2020-02-18 13:22     ` Peter Zijlstra
2020-02-18 14:15       ` Vincent Guittot
2020-02-19 11:07         ` Dietmar Eggemann
2020-02-19 16:26           ` Vincent Guittot
2020-02-20 13:38             ` Dietmar Eggemann
     [not found]               ` <20200222152541.GA11669@geo.homenetwork>
2020-02-26 16:30                 ` Vincent Guittot
2020-02-14 15:27 ` [PATCH v2 2/5] sched/numa: Replace runnable_load_avg by load_avg Vincent Guittot
2020-02-18 12:37   ` Dietmar Eggemann
2020-02-18 13:50     ` Mel Gorman
2020-02-18 14:17       ` Vincent Guittot
2020-02-18 14:42         ` Dietmar Eggemann
2020-02-18 14:54   ` Valentin Schneider
2020-02-18 15:33     ` Vincent Guittot
2020-02-18 15:38     ` Mel Gorman
2020-02-18 16:50       ` Valentin Schneider
2020-02-18 17:41         ` Mel Gorman
2020-02-18 17:54           ` Valentin Schneider
2020-02-18 16:51       ` Vincent Guittot
2020-02-14 15:27 ` [PATCH v2 3/5] sched/pelt: Remove unused runnable load average Vincent Guittot
2020-02-21  9:57   ` Dietmar Eggemann
2020-02-21 11:56     ` Vincent Guittot
2020-02-14 15:27 ` [PATCH v2 4/5] sched/pelt: Add a new runnable average signal Vincent Guittot
2020-02-18 14:54   ` Valentin Schneider
2020-02-18 15:12     ` Peter Zijlstra
2020-02-18 15:28     ` Vincent Guittot
2020-02-18 16:30       ` Valentin Schneider
2020-02-18 21:19   ` Valentin Schneider
2020-02-19  9:02     ` Vincent Guittot
2020-02-19  9:08     ` Mel Gorman
2020-02-19 12:55   ` [PATCH v3 " Vincent Guittot
2020-02-19 14:02     ` Mel Gorman
2020-02-19 20:10     ` Valentin Schneider
2020-02-20 14:36       ` Vincent Guittot
2020-02-20 16:11         ` Valentin Schneider
2020-02-21  8:56           ` Vincent Guittot
2020-02-24 15:57             ` Valentin Schneider
2020-02-21  9:04           ` Mel Gorman
2020-02-21  9:25             ` Vincent Guittot
2020-02-21 10:40               ` Mel Gorman
2020-02-21 13:28                 ` Vincent Guittot
2020-02-20 15:04     ` Dietmar Eggemann
2020-02-21  9:44     ` Dietmar Eggemann
2020-02-21 11:47       ` Vincent Guittot
2020-02-14 15:27 ` [PATCH v2 5/5] sched/fair: Take into account runnable_avg to classify group Vincent Guittot
2020-02-15 21:58 ` Mel Gorman [this message]
2020-02-21  9:58 ` [PATCH v2 0/5] remove runnable_load_avg and improve group_classify Dietmar Eggemann

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=20200215215823.GY3420@suse.de \
    --to=mgorman@suse.de \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=hdanton@sina.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=parth@linux.ibm.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --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).