From: Matt Fleming <matt@codeblueprint.co.uk>
To: Peter Zijlstra <peterz@infradead.org>
Cc: mingo@kernel.org, tglx@linutronix.de, riel@redhat.com,
hpa@zytor.com, efault@gmx.de, linux-kernel@vger.kernel.org,
torvalds@linux-foundation.org, lvenanci@redhat.com,
xiaolong.ye@intel.com, kitsunyan@inbox.ru, clm@fb.com
Subject: Re: hackbench vs select_idle_sibling; was: [tip:sched/core] sched/fair, cpumask: Export for_each_cpu_wrap()
Date: Wed, 17 May 2017 13:46:35 +0100 [thread overview]
Message-ID: <20170517124635.GB3229@codeblueprint.co.uk> (raw)
In-Reply-To: <20170517105350.hk5m4h4jb6dfr65a@hirez.programming.kicks-ass.net>
On Wed, 17 May, at 12:53:50PM, Peter Zijlstra wrote:
> On Mon, May 15, 2017 at 02:03:11AM -0700, tip-bot for Peter Zijlstra wrote:
> > sched/fair, cpumask: Export for_each_cpu_wrap()
>
> > -static int cpumask_next_wrap(int n, const struct cpumask *mask, int start, int *wrapped)
> > -{
>
> > - next = find_next_bit(cpumask_bits(mask), nr_cpumask_bits, n+1);
>
> > -}
>
> OK, so this patch fixed an actual bug in the for_each_cpu_wrap()
> implementation. The above 'n+1' should be 'n', and the effect is that
> it'll skip over CPUs, potentially resulting in an iteration that only
> sees every other CPU (for a fully contiguous mask).
>
> This in turn causes hackbench to further suffer from the regression
> introduced by commit:
>
> 4c77b18cf8b7 ("sched/fair: Make select_idle_cpu() more aggressive")
>
> So its well past time to fix this.
>
> Where the old scheme was a cliff-edge throttle on idle scanning, this
> introduces a more gradual approach. Instead of stopping to scan
> entirely, we limit how many CPUs we scan.
>
> Initial benchmarks show that it mostly recovers hackbench while not
> hurting anything else, except Mason's schbench, but not as bad as the
> old thing.
>
> It also appears to recover the tbench high-end, which also suffered like
> hackbench.
>
> I'm also hoping it will fix/preserve kitsunyan's interactivity issue.
>
> Please test..
Tests queued up at SUSE. I'll let you know the results as soon as
they're ready -- it'll be at least a couple of days.
next prev parent reply other threads:[~2017-05-17 12:46 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 13:56 [RFC 0/3] sched/topology: fix sched groups on NUMA machines with mesh topology Lauro Ramos Venancio
2017-04-13 13:56 ` [RFC 1/3] sched/topology: Refactor function build_overlap_sched_groups() Lauro Ramos Venancio
2017-04-13 14:50 ` Rik van Riel
2017-05-15 9:02 ` [tip:sched/core] " tip-bot for Lauro Ramos Venancio
2017-04-13 13:56 ` [RFC 2/3] sched/topology: fix sched groups on NUMA machines with mesh topology Lauro Ramos Venancio
2017-04-13 15:16 ` Rik van Riel
2017-04-13 15:48 ` Peter Zijlstra
2017-04-13 20:21 ` Lauro Venancio
2017-04-13 21:06 ` Lauro Venancio
2017-04-13 23:38 ` Rik van Riel
2017-04-14 10:48 ` Peter Zijlstra
2017-04-14 11:38 ` Peter Zijlstra
2017-04-14 12:20 ` Peter Zijlstra
2017-05-15 9:03 ` [tip:sched/core] sched/fair, cpumask: Export for_each_cpu_wrap() tip-bot for Peter Zijlstra
2017-05-17 10:53 ` hackbench vs select_idle_sibling; was: " Peter Zijlstra
2017-05-17 12:46 ` Matt Fleming [this message]
2017-05-17 14:49 ` Chris Mason
2017-05-19 15:00 ` Matt Fleming
2017-06-05 13:00 ` Matt Fleming
2017-06-06 9:21 ` Peter Zijlstra
2017-06-09 17:52 ` Chris Mason
2017-06-08 9:22 ` [tip:sched/core] sched/core: Implement new approach to scale select_idle_cpu() tip-bot for Peter Zijlstra
2017-04-14 16:58 ` [RFC 2/3] sched/topology: fix sched groups on NUMA machines with mesh topology Peter Zijlstra
2017-04-17 14:40 ` Lauro Venancio
2017-04-13 13:56 ` [RFC 3/3] sched/topology: Different sched groups must not have the same balance cpu Lauro Ramos Venancio
2017-04-13 15:27 ` Rik van Riel
2017-04-14 16:49 ` Peter Zijlstra
2017-04-17 15:34 ` Lauro Venancio
2017-04-18 12:32 ` Peter Zijlstra
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=20170517124635.GB3229@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--cc=clm@fb.com \
--cc=efault@gmx.de \
--cc=hpa@zytor.com \
--cc=kitsunyan@inbox.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=lvenanci@redhat.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=xiaolong.ye@intel.com \
/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.