From: Peter Zijlstra <peterz@infradead.org>
To: Steven Sistare <steven.sistare@oracle.com>
Cc: mingo@redhat.com, subhra.mazumdar@oracle.com,
dhaval.giani@oracle.com, rohit.k.jain@oracle.com,
daniel.m.jordan@oracle.com, pavel.tatashin@microsoft.com,
matt@codeblueprint.co.uk, umgwanakikbuti@gmail.com,
riel@redhat.com, jbacik@fb.com, juri.lelli@redhat.com,
linux-kernel@vger.kernel.org, srikar@linux.vnet.ibm.com
Subject: Re: [PATCH 09/10] sched/fair: disable stealing if too many NUMA nodes
Date: Tue, 23 Oct 2018 00:05:09 +0200 [thread overview]
Message-ID: <20181022220509.GC3109@worktop.c.hoisthospitality.com> (raw)
In-Reply-To: <274b79fd-b001-3d30-3773-7f01940ca8a6@oracle.com>
On Mon, Oct 22, 2018 at 03:21:20PM -0400, Steven Sistare wrote:
> On 10/22/2018 2:47 PM, Steven Sistare wrote:
> > On 10/22/2018 1:06 PM, Peter Zijlstra wrote:
> >> On Mon, Oct 22, 2018 at 07:59:40AM -0700, Steve Sistare wrote:
> >>> The STEAL feature causes regressions on hackbench on larger NUMA systems,
> >>> so disable it on systems with more than sched_steal_node_limit nodes
> >>> (default 2).
> >>
> >> How come? From a quick read the stealing is per LLC, where do we steal
> >> across nodes?
> >
> > See the complete explanation in this patch. It is deeper than can be gleaned
> > from a quick read.
>
> I should have said a bit more. Your quick take on stealing is correct, we do
> not steal across nodes. However, stealing reduces average run queue length which
> influences wake_affine migrations. Now see the complete explanation.
Right; read a bit more just now.
hackbench is a fairly poor benchmark for numa performance. One that
comes to mind is multi wharehouse specjbb stuff (assuming you have numa
balance enabled of course).
next prev parent reply other threads:[~2018-10-22 22:22 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 14:59 [PATCH 00/10] steal tasks to improve CPU utilization Steve Sistare
2018-10-22 14:59 ` [PATCH 01/10] sched: Provide sparsemask, a reduced contention bitmap Steve Sistare
2018-10-22 14:59 ` [PATCH 02/10] sched/topology: Provide hooks to allocate data shared per LLC Steve Sistare
2018-10-22 14:59 ` [PATCH 03/10] sched/topology: Provide cfs_overload_cpus bitmap Steve Sistare
2018-10-22 14:59 ` [PATCH 04/10] sched/fair: Dynamically update cfs_overload_cpus Steve Sistare
2018-10-22 16:56 ` Peter Zijlstra
2018-10-22 18:43 ` Steven Sistare
2018-10-22 14:59 ` [PATCH 05/10] sched/fair: Hoist idle_stamp up from idle_balance Steve Sistare
2018-10-25 13:47 ` Valentin Schneider
2018-10-25 14:04 ` Steven Sistare
2018-10-22 14:59 ` [PATCH 06/10] sched/fair: Generalize the detach_task interface Steve Sistare
2018-10-22 14:59 ` [PATCH 07/10] sched/fair: Provide can_migrate_task_llc Steve Sistare
2018-10-26 18:04 ` Valentin Schneider
2018-10-26 18:28 ` Steven Sistare
2018-10-29 19:34 ` Valentin Schneider
2018-10-31 15:43 ` Steven Sistare
2018-10-31 18:48 ` Valentin Schneider
2018-10-31 19:14 ` Peter Zijlstra
2018-11-01 11:16 ` Valentin Schneider
2018-10-22 14:59 ` [PATCH 08/10] sched/fair: Steal work from an overloaded CPU when CPU goes idle Steve Sistare
2018-10-25 13:48 ` Valentin Schneider
2018-10-25 14:07 ` Steven Sistare
2018-10-22 14:59 ` [PATCH 09/10] sched/fair: disable stealing if too many NUMA nodes Steve Sistare
2018-10-22 17:06 ` Peter Zijlstra
2018-10-22 18:47 ` Steven Sistare
2018-10-22 19:21 ` Steven Sistare
2018-10-22 22:05 ` Peter Zijlstra [this message]
2018-10-23 13:18 ` Steven Sistare
2018-10-22 14:59 ` [PATCH 10/10] sched/fair: Provide idle search schedstats Steve Sistare
2018-10-22 17:04 ` [PATCH 00/10] steal tasks to improve CPU utilization Peter Zijlstra
2018-10-22 19:07 ` Steven Sistare
2018-10-22 22:09 ` Peter Zijlstra
2018-10-24 15:34 ` Valentin Schneider
2018-10-24 19:27 ` Steven Sistare
2018-10-25 11:31 ` Valentin Schneider
2018-10-25 12:21 ` Steven Sistare
2018-10-25 7:50 ` Vincent Guittot
2018-10-25 11:28 ` Steven Sistare
2018-10-25 12:43 ` Vincent Guittot
2018-10-25 14:19 ` Steven Sistare
2018-10-31 19:35 ` Steven Sistare
2018-11-01 11:56 ` Steven Sistare
2018-11-02 23:39 ` Subhra Mazumdar
2018-11-05 20:08 ` Steven Sistare
2019-01-04 13:37 ` Shijith Thotton
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=20181022220509.GC3109@worktop.c.hoisthospitality.com \
--to=peterz@infradead.org \
--cc=daniel.m.jordan@oracle.com \
--cc=dhaval.giani@oracle.com \
--cc=jbacik@fb.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@redhat.com \
--cc=pavel.tatashin@microsoft.com \
--cc=riel@redhat.com \
--cc=rohit.k.jain@oracle.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=steven.sistare@oracle.com \
--cc=subhra.mazumdar@oracle.com \
--cc=umgwanakikbuti@gmail.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.