From: Shakeel Butt <shakeel.butt@linux.dev>
To: "Chen, Yu C" <yu.c.chen@intel.com>
Cc: peterz@infradead.org, akpm@linux-foundation.org,
mkoutny@suse.com, mingo@redhat.com, tj@kernel.org,
hannes@cmpxchg.org, corbet@lwn.net, mgorman@suse.de,
mhocko@kernel.org, muchun.song@linux.dev,
roman.gushchin@linux.dev, tim.c.chen@intel.com,
aubrey.li@intel.com, libo.chen@oracle.com,
kprateek.nayak@amd.com, vineethr@linux.ibm.com,
venkat88@linux.ibm.com, ayushjai@amd.com,
cgroups@vger.kernel.org, linux-doc@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
yu.chen.surf@foxmail.com
Subject: Re: [PATCH v5 2/2] sched/numa: add statistics of numa balance task
Date: Tue, 27 May 2025 10:48:23 -0700 [thread overview]
Message-ID: <qcasnjdjet57uxhwavfiaxepq7anf2zvmi4rzkp5lxysovqwme@wwcyh4nvlxiv> (raw)
In-Reply-To: <52a1b56b-9598-499d-ac9c-de99479d5166@intel.com>
On Sun, May 25, 2025 at 08:35:24PM +0800, Chen, Yu C wrote:
> On 5/25/2025 1:32 AM, Shakeel Butt wrote:
[...]
> > can you please give an end-to-end> flow/story of all these events
> happening on a timeline.
> >
>
> Yes, sure, let me have a try.
>
> The goal of NUMA balancing is to co-locate a task and its
> memory pages on the same NUMA node. There are two strategies:
> migrate the pages to the task's node, or migrate the task to
> the node where its pages reside.
>
> Suppose a task p1 is running on Node 0, but its pages are
> located on Node 1. NUMA page fault statistics for p1 reveal
> its "page footprint" across nodes. If NUMA balancing detects
> that most of p1's pages are on Node 1:
>
> 1.Page Migration Attempt:
> The Numa balance first tries to migrate p1's pages to Node 0.
> The numa_page_migrate counter increments.
>
> 2.Task Migration Strategies:
> After the page migration finishes, Numa balance checks every
> 1 second to see if p1 can be migrated to Node 1.
>
> Case 2.1: Idle CPU Available
> If Node 1 has an idle CPU, p1 is directly scheduled there. This event is
> logged as numa_task_migrated.
> Case 2.2: No Idle CPU (Task Swap)
> If all CPUs on Node1 are busy, direct migration could cause CPU contention
> or load imbalance. Instead:
> The Numa balance selects a candidate task p2 on Node 1 that prefers
> Node 0 (e.g., due to its own page footprint).
> p1 and p2 are swapped. This cross-node swap is recorded as
> numa_task_swapped.
>
Thanks for the explanation, this is really helpful and I would like this
to be included in the commit message.
> > Beside that, do you think there might be some other scheduling events
> > (maybe unrelated to numa balancing) which might be suitable for
> > memory.stat? Basically I am trying to find if having sched events in
> > memory.stat be an exception for numa balancing or more general.
>
> If the criterion is a combination of task scheduling strategy and
> page-based operations, I cannot find any other existing scheduling
> events. For now, NUMA balancing seems to be the only case.
Mainly I was looking if in future we need to add more sched events to
memory.stat file.
Let me reply on the other email chain on what should we do next.
next prev parent reply other threads:[~2025-05-27 17:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-23 12:48 [PATCH v5 0/2] sched/numa: add statistics of numa balance task migration Chen Yu
2025-05-23 12:51 ` [PATCH v5 1/2] sched/numa: fix task swap by skipping kernel threads Chen Yu
2025-05-23 23:22 ` Shakeel Butt
2025-05-23 12:51 ` [PATCH v5 2/2] sched/numa: add statistics of numa balance task Chen Yu
2025-05-23 23:42 ` Shakeel Butt
2025-05-24 9:07 ` Chen, Yu C
2025-05-24 17:32 ` Shakeel Butt
2025-05-25 12:35 ` Chen, Yu C
2025-05-27 17:48 ` Shakeel Butt [this message]
2025-05-29 5:04 ` Chen, Yu C
2025-05-26 13:35 ` Michal Koutný
2025-05-27 9:20 ` Chen, Yu C
2025-05-27 18:15 ` Shakeel Butt
2025-06-02 16:53 ` Michal Koutný
2025-06-03 14:46 ` Chen, Yu C
2025-06-17 9:30 ` Michal Koutný
2025-06-19 13:03 ` Chen, Yu C
2025-06-19 14:06 ` Michal Koutný
2025-05-23 22:06 ` [PATCH v5 0/2] sched/numa: add statistics of numa balance task migration Andrew Morton
2025-05-23 23:52 ` Shakeel Butt
2025-05-28 0:21 ` Andrew Morton
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=qcasnjdjet57uxhwavfiaxepq7anf2zvmi4rzkp5lxysovqwme@wwcyh4nvlxiv \
--to=shakeel.butt@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=aubrey.li@intel.com \
--cc=ayushjai@amd.com \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=hannes@cmpxchg.org \
--cc=kprateek.nayak@amd.com \
--cc=libo.chen@oracle.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=peterz@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=tim.c.chen@intel.com \
--cc=tj@kernel.org \
--cc=venkat88@linux.ibm.com \
--cc=vineethr@linux.ibm.com \
--cc=yu.c.chen@intel.com \
--cc=yu.chen.surf@foxmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox