From: Mel Gorman <firstname.lastname@example.org> To: Peter Zijlstra <email@example.com> Cc: Vincent Guittot <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Juri Lelli <firstname.lastname@example.org>, Dietmar Eggemann <email@example.com>, Steven Rostedt <firstname.lastname@example.org>, Ben Segall <email@example.com>, Valentin Schneider <firstname.lastname@example.org>, Phil Auld <email@example.com>, LKML <firstname.lastname@example.org> Subject: Re: [PATCH 08/11] sched/numa: Bias swapping tasks based on their preferred node Date: Thu, 13 Feb 2020 11:18:02 +0000 [thread overview] Message-ID: <20200213111802.GW3466@techsingularity.net> (raw) In-Reply-To: <20200213103108.GG14914@hirez.programming.kicks-ass.net> On Thu, Feb 13, 2020 at 11:31:08AM +0100, Peter Zijlstra wrote: > On Wed, Feb 12, 2020 at 09:36:51AM +0000, Mel Gorman wrote: > > When swapping tasks for NUMA balancing, it is preferred that tasks move > > to or remain on their preferred node. When considering an imbalance, > > encourage tasks to move to their preferred node and discourage tasks from > > moving away from their preferred node. > > Wasn't there an issue for workloads that span multiple nodes? > Sortof, yes -- specifically workloads that could not fit inside a node for whatever reason. > Say a 4 node system with 2 warehouses? Then each JVM will want 2 nodes, > instead of a single node, and strong preferred node stuff makes it > difficult to achieve this. > > I forgot how we dealt with these cases, just something I worry about > when reading this. We deal with it in task_numa_migrate() by considering nodes other than the preferred node for placement -- see "Look at other nodes in these cases" followed by a sched_setnuma if the preferred node doesn't match. We do not do any special casing as such in task_numa_compare other than finding the best improvement so we can pick a task belonging to a group spanning multiple nodes with or without this patch. A workload spanning multiple nodes in itself does not justify a full search if it can be avoided. -- Mel Gorman SUSE Labs
next prev parent reply other threads:[~2020-02-13 11:18 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-12 9:36 [RFC PATCH 00/11] Reconcile NUMA balancing decisions with the load balancer Mel Gorman 2020-02-12 9:36 ` [PATCH 01/11] sched/fair: Allow a small load imbalance between low utilisation SD_NUMA domains Mel Gorman 2020-02-12 9:36 ` [PATCH 02/11] sched/fair: Optimize select_idle_core() Mel Gorman 2020-02-12 9:36 ` [PATCH 03/11] sched/fair: Allow a per-CPU kthread waking a task to stack on the same CPU, to fix XFS performance regression Mel Gorman 2020-02-12 9:36 ` [PATCH 04/11] sched/numa: Trace when no candidate CPU was found on the preferred node Mel Gorman 2020-02-12 9:36 ` [PATCH 05/11] sched/numa: Distinguish between the different task_numa_migrate failure cases Mel Gorman 2020-02-12 14:43 ` Steven Rostedt 2020-02-12 15:59 ` Mel Gorman 2020-02-12 9:36 ` [PATCH 06/11] sched/numa: Prefer using an idle cpu as a migration target instead of comparing tasks Mel Gorman 2020-02-12 9:36 ` [PATCH 07/11] sched/numa: Find an alternative idle CPU if the CPU is part of an active NUMA balance Mel Gorman 2020-02-12 9:36 ` [PATCH 08/11] sched/numa: Bias swapping tasks based on their preferred node Mel Gorman 2020-02-13 10:31 ` Peter Zijlstra 2020-02-13 11:18 ` Mel Gorman [this message] 2020-02-12 13:22 ` [RFC PATCH 00/11] Reconcile NUMA balancing decisions with the load balancer Vincent Guittot 2020-02-12 14:07 ` Valentin Schneider 2020-02-12 15:48 ` Mel Gorman 2020-02-12 16:13 ` Vincent Guittot 2020-02-12 15:45 ` [PATCH 09/11] sched/fair: Split out helper to adjust imbalances between domains Mel Gorman 2020-02-12 15:46 ` [PATCH 10/11] sched/numa: Use similar logic to the load balancer for moving between domains with spare capacity Mel Gorman 2020-02-12 15:46 ` [PATCH 11/11] sched/numa: Use similar logic to the load balancer for moving between overloaded domains Mel Gorman [not found] ` <email@example.com> 2020-02-14 7:50 ` [PATCH 08/11] sched/numa: Bias swapping tasks based on their preferred node Mel Gorman
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=20200213111802.GW3466@techsingularity.net \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 08/11] sched/numa: Bias swapping tasks based on their preferred node' \ /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
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).