From: K Prateek Nayak <kprateek.nayak@amd.com>
To: Libo Chen <libo.chen@oracle.com>, <akpm@linux-foundation.org>,
<rostedt@goodmis.org>, <peterz@infradead.org>, <mgorman@suse.de>,
<mingo@redhat.com>, <juri.lelli@redhat.com>,
<vincent.guittot@linaro.org>, <tj@kernel.org>, <llong@redhat.com>
Cc: <sraithal@amd.com>, <venkat88@linux.ibm.com>,
<raghavendra.kt@amd.com>, <yu.c.chen@intel.com>,
<tim.c.chen@intel.com>, <vineethr@linux.ibm.com>,
<chris.hyser@oracle.com>, <daniel.m.jordan@oracle.com>,
<lorenzo.stoakes@oracle.com>, <mkoutny@suse.com>,
<linux-mm@kvack.org>, <cgroups@vger.kernel.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 0/2] sched/numa: Skip VMA scanning on memory pinned to one NUMA node via cpuset.mems
Date: Thu, 24 Apr 2025 10:12:32 +0530 [thread overview]
Message-ID: <98092a32-f903-49a3-a5b6-7edffa9edd55@amd.com> (raw)
In-Reply-To: <20250424024523.2298272-1-libo.chen@oracle.com>
Hello Libo,
On 4/24/2025 8:15 AM, Libo Chen wrote:
> v1->v2:
> 1. add perf improvment numbers in commit log. Yet to find perf diff on
> will-it-scale, so not included here. Plan to run more workloads.
> 2. add tracepoint.
> 3. To peterz's comment, this will make it impossible to attract tasks to
> those memory just like other VMA skippings. This is the current
> implementation, I think we can improve that in the future, but at the
> moment it's probabaly better to keep it consistent.
I tested the series with hackbench running on a dual socket system with
memory pinned to one node and I could see the skip_cpuset_numa traces
being logged:
sched-messaging-9430 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9430 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9640 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9640 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9645 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9645 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9637 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9637 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9629 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9629 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9639 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9639 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9630 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9630 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9487 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9487 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9635 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9635 tgid=9007 ngid=0 mem_nodes_allowed=0
sched-messaging-9647 ...: sched_skip_cpuset_numa: comm=sched-messaging pid=9647 tgid=9007 ngid=0 mem_nodes_allowed=0
...
Feel free to add:
Tested-by: K Prateek Nayak <kprateek.nayak@amd.com>
--
Thanks and Regards,
Prateek
>
> v2->v3:
> 1. add enable_cpuset() based on Mel's suggestion but again I think it's
> redundant.
> 2. print out nodemask with %*p.. format in the tracepoint.
>
> v3->v4:
> 1. fix an unsafe dereference of a pointer to content not on ring buffer,
> namely mem_allowed_ptr in the tracepoint.
>
> v4->v5:
> 1. add BUILD_BUG_ON() in TP_fast_assign() to guard against future
> changes (particularly in size) in nodemask_t.
>
> Libo Chen (2):
> sched/numa: Skip VMA scanning on memory pinned to one NUMA node via
> cpuset.mems
> sched/numa: Add tracepoint that tracks the skipping of numa balancing
> due to cpuset memory pinning
>
> include/trace/events/sched.h | 33 +++++++++++++++++++++++++++++++++
> kernel/sched/fair.c | 9 +++++++++
> 2 files changed, 42 insertions(+)
>
next prev parent reply other threads:[~2025-04-24 4:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-24 2:45 Libo Chen
2025-04-24 2:45 ` [PATCH v5 1/2] " Libo Chen
2025-04-24 2:45 ` [PATCH v5 2/2] sched/numa: Add tracepoint that tracks the skipping of numa balancing due to cpuset memory pinning Libo Chen
2025-04-24 4:42 ` K Prateek Nayak [this message]
2025-04-24 7:05 ` [PATCH v5 0/2] sched/numa: Skip VMA scanning on memory pinned to one NUMA node via cpuset.mems Venkat Rao Bagalkote
2025-04-24 7:46 ` Libo Chen
2025-04-24 9:47 ` Venkat Rao Bagalkote
2025-04-24 7:52 ` Aithal, Srikanth
2025-04-24 9:50 ` Venkat Rao Bagalkote
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=98092a32-f903-49a3-a5b6-7edffa9edd55@amd.com \
--to=kprateek.nayak@amd.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=chris.hyser@oracle.com \
--cc=daniel.m.jordan@oracle.com \
--cc=juri.lelli@redhat.com \
--cc=libo.chen@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=llong@redhat.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=peterz@infradead.org \
--cc=raghavendra.kt@amd.com \
--cc=rostedt@goodmis.org \
--cc=sraithal@amd.com \
--cc=tim.c.chen@intel.com \
--cc=tj@kernel.org \
--cc=venkat88@linux.ibm.com \
--cc=vincent.guittot@linaro.org \
--cc=vineethr@linux.ibm.com \
--cc=yu.c.chen@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox