All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@suse.de>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Peter Puhov <peter.puhov@linaro.org>,
	Valentin Schneider <valentin.schneider@arm.com>,
	linux-kernel@vger.kernel.org,
	Robert Foley <robert.foley@linaro.org>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>
Subject: Re: [PATCH] sched/fair: update_pick_idlest() Select group with lowest group_util when idle_cpus are equal
Date: Thu, 2 Jul 2020 14:20:58 +0100	[thread overview]
Message-ID: <20200702132058.GN3129@suse.de> (raw)
In-Reply-To: <106350c5-c2b7-a63c-2b06-761f523ee67c@arm.com>

On Thu, Jul 02, 2020 at 11:27:52AM +0200, Dietmar Eggemann wrote:
> On 17/06/2020 16:52, Peter Puhov wrote:
> > On Wed, 17 Jun 2020 at 06:50, Valentin Schneider
> > <valentin.schneider@arm.com> wrote:
> >>
> >>
> >> On 16/06/20 17:48, peter.puhov@linaro.org wrote:
> >>> From: Peter Puhov <peter.puhov@linaro.org>
> >>> We tested this patch with following benchmarks:
> >>>   perf bench -f simple sched pipe -l 4000000
> >>>   perf bench -f simple sched messaging -l 30000
> >>>   perf bench -f simple  mem memset -s 3GB -l 15 -f default
> >>>   perf bench -f simple futex wake -s -t 640 -w 1
> >>>   sysbench cpu --threads=8 --cpu-max-prime=10000 run
> >>>   sysbench memory --memory-access-mode=rnd --threads=8 run
> >>>   sysbench threads --threads=8 run
> >>>   sysbench mutex --mutex-num=1 --threads=8 run
> >>>   hackbench --loops 20000
> >>>   hackbench --pipe --threads --loops 20000
> >>>   hackbench --pipe --threads --loops 20000 --datasize 4096
> >>>
> >>> and found some performance improvements in:
> >>>   sysbench threads
> >>>   sysbench mutex
> >>>   perf bench futex wake
> >>> and no regressions in others.
> >>>
> >>
> >> One nitpick for the results of those: condensing them in a table form would
> >> make them more reader-friendly. Perhaps something like:
> >>
> >> | Benchmark        | Metric   | Lower is better? | BASELINE | SERIES | DELTA |
> >> |------------------+----------+------------------+----------+--------+-------|
> >> | Sysbench threads | # events | No               |    45526 |  56567 |  +24% |
> >> | Sysbench mutex   | ...      |                  |          |        |       |
> >>
> >> If you want to include more stats for each benchmark, you could have one table
> >> per (e.g. see [1]) - it'd still be a more readable form (or so I believe).
> 
> Wouldn't Unix Bench's 'execl' and 'spawn' be the ultimate test cases
> for those kind of changes?
> 
> I only see minor improvements with tip/sched/core as base on hikey620
> (Arm64 octa-core).
> 
> 				base		w/ patch
> ./Run spawn -c 8 -i 10		 633.6		 635.1
> 
> ./Run execl -c 8 -i 10		1187.5		1190.7	
> 
> 
> At the end of find_idlest_group(), when comparing local and idlest, it
> is explicitly mentioned that number of idle_cpus is used instead of
> utilization.
> The comparision between potential idle groups and local & idlest group
> should probably follow the same rules.
> 

There is the secondary hazard that what update_sd_pick_busiest returns
is checked later by find_busiest_group when considering the imbalance
between NUMA nodes. This particular patch splits basic communicating tasks
cross-node again at fork time so cross node communication is reintroduced
(same applies if sum_nr_running is used instead of group_util).

-- 
Mel Gorman
SUSE Labs

  reply	other threads:[~2020-07-02 13:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 16:48 [PATCH] sched/fair: update_pick_idlest() Select group with lowest group_util when idle_cpus are equal peter.puhov
2020-06-17 10:50 ` Valentin Schneider
2020-06-17 14:52   ` Peter Puhov
2020-07-02  9:27     ` Dietmar Eggemann
2020-07-02 13:20       ` Mel Gorman [this message]
2020-07-02 13:45         ` Vincent Guittot
2020-07-01  9:19 ` [sched/fair] 0b9730e694: vm-scalability.throughput 7.7% improvement kernel test robot

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=20200702132058.GN3129@suse.de \
    --to=mgorman@suse.de \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peter.puhov@linaro.org \
    --cc=peterz@infradead.org \
    --cc=robert.foley@linaro.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 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.