All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Huang Ying <ying.huang@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Mel Gorman <mgorman@suse.de>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Rik van Riel <riel@surriel.com>
Subject: Re: [RFC PATCH 2/2] NUMA balancing: avoid to migrate task to CPU-less node
Date: Fri, 28 Jan 2022 11:03:41 +0530	[thread overview]
Message-ID: <20220128053341.GB618915@linux.vnet.ibm.com> (raw)
In-Reply-To: <20220128023842.1946583-2-ying.huang@intel.com>

* Huang Ying <ying.huang@intel.com> [2022-01-28 10:38:42]:

> In a typical memory tiering system, there's no CPU in slow (PMEM) NUMA
> nodes.  But if the number of the hint page faults on a PMEM node is
> the max for a task, The current NUMA balancing policy may try to place
> the task on the PMEM node instead of DRAM node.  This is unreasonable,
> because there's no CPU in PMEM NUMA nodes.  To fix this, CPU-less
> nodes are ignored when searching the migration target node for a task
> in this patch.
> 
> To test the patch, we run a workload that accesses more memory in PMEM
> node than memory in DRAM node.  Without the patch, the PMEM node will
> be chosen as preferred node in task_numa_placement().  While the DRAM
> node will be chosen instead with the patch.
> 
> Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Mel Gorman <mgorman@suse.de>
> Cc: Rik van Riel <riel@surriel.com>
> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> ---
>  kernel/sched/fair.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 54e1aad1c5d7..e462ac5c1e48 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2393,6 +2393,10 @@ static void task_numa_placement(struct task_struct *p)
>  			}
>  		}
> 
> +		/* Cannot migrate task to CPU-less node */
> +		if (!node_state(nid, N_CPU))
> +			continue;
> +

Lets take the example that you quoted 2 socket machine with 1 DRAM node and
1 PMEM node per socket.  Now lets say the task is placed on a CPU in node 1
but most of its memory faults are coming from node 2, which is the PMEM node
attached to node 0. Now without the hunk, there is a chance that the task
got moved to node 0. However with the change, are we inhibiting such a move?

>  		if (!ng) {
>  			if (faults > max_faults) {
>  				max_faults = faults;
> -- 
> 2.30.2
> 

-- 
Thanks and Regards
Srikar Dronamraju

  reply	other threads:[~2022-01-28  5:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-28  2:38 [RFC PATCH 1/2] NUMA balancing: fix NUMA topology type for memory tiering system Huang Ying
2022-01-28  2:38 ` [RFC PATCH 2/2] NUMA balancing: avoid to migrate task to CPU-less node Huang Ying
2022-01-28  5:33   ` Srikar Dronamraju [this message]
2022-01-28  7:51     ` Huang, Ying
2022-02-01  5:59       ` Srikar Dronamraju
2022-02-08  8:19         ` Huang, Ying
2022-01-28  5:23 ` [RFC PATCH 1/2] NUMA balancing: fix NUMA topology type for memory tiering system Srikar Dronamraju
2022-01-28  7:30   ` Huang, Ying
2022-01-28 15:13     ` Peter Zijlstra
2022-01-30  1:07       ` Huang, Ying
2022-01-28 15:06 ` Peter Zijlstra
2022-01-28 17:08   ` Valentin Schneider

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=20220128053341.GB618915@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=ying.huang@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.