From: Dhaval Giani <dhaval@gianis.ca>
To: Chris Hyser <chris.hyser@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Mel Gorman <mgorman@techsingularity.net>,
longman@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] sched/numa: Add ability to override task's numa_preferred_nid.
Date: Tue, 10 Jun 2025 18:31:17 +0000 [thread overview]
Message-ID: <aEh57Evd4WmrrvJx@fedora> (raw)
In-Reply-To: <20250415013625.3922497-1-chris.hyser@oracle.com>
On Mon, Apr 14, 2025 at 09:35:51PM -0400, Chris Hyser wrote:
> From: chris hyser <chris.hyser@oracle.com>
>
> This patch allows directly setting and subsequent overriding of a task's
> "Preferred Node Affinity" by setting the task's numa_preferred_nid and
> relying on the existing NUMA balancing infrastructure.
>
> NUMA balancing introduced the notion of tracking and using a task's
> preferred memory node for both migrating/consolidating the physical pages
> accessed by a task and to assist the scheduler in making NUMA aware
> placement and load balancing decisions.
>
> The existing mechanism for determining this, Auto NUMA Balancing, relies
> on periodic removal of virtual mappings for blocks of a task's address
> space. The resulting faults can indicate a preference for an accessed
> node.
>
> This has two issues that this patch seeks to overcome:
>
> - there is a trade-off between faulting overhead and the ability to detect
> dynamic access patterns. In cases where the task or user understand the
> NUMA sensitivities, this patch can enable the benefits of setting a
> preferred node used either in conjunction with Auto NUMA Balancing's
> default parameters or adjusting the NUMA balance parameters to reduce the
> faulting rate (potentially to 0).
>
> - memory pinned to nodes or to physical addresses such as RDMA cannot be
> migrated and have thus far been excluded from the scanning. Not taking
> those faults however can prevent Auto NUMA Balancing from reliably
> detecting a node preference with the scheduler load balancer then
> possibly operating with incorrect NUMA information.
>
> The following results were from TPCC runs on an Oracle Database. The system
> was a 2-node Intel machine with a database running on each node with local
> memory allocations. No tasks or memory were pinned.
>
> There are four scenarios of interest:
>
> - Auto NUMA Balancing OFF.
> base value
>
> - Auto NUMA Balancing ON.
> 1.2% - ANB ON better than ANB OFF.
>
> - Use the prctl(), ANB ON, parameters set to prevent faulting.
> 2.4% - prctl() better then ANB OFF.
> 1.2% - prctl() better than ANB ON.
>
> - Use the prctl(), ANB parameters normal.
> 3.1% - prctl() and ANB ON better than ANB OFF.
> 1.9% - prctl() and ANB ON better than just ANB ON.
> 0.7% - prctl() and ANB ON better than prctl() and ANB ON/faulting off
>
> In benchmarks pinning large regions of heavily accessed memory, the
> advantages of the prctl() over Auto NUMA Balancing alone is significantly
> higher.
>
> Signed-off-by: Chris Hyser <chris.hyser@oracle.com>
> ---
> include/linux/sched.h | 1 +
> init/init_task.c | 1 +
> kernel/sched/core.c | 5 ++++-
> kernel/sched/debug.c | 1 +
> kernel/sched/fair.c | 15 +++++++++++++--
> 5 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index f96ac1982893..373046c82b35 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1350,6 +1350,7 @@ struct task_struct {
> short pref_node_fork;
> #endif
> #ifdef CONFIG_NUMA_BALANCING
> + int numa_preferred_nid_force;
> int numa_scan_seq;
> unsigned int numa_scan_period;
> unsigned int numa_scan_period_max;
> diff --git a/init/init_task.c b/init/init_task.c
> index e557f622bd90..1921a87326db 100644
> --- a/init/init_task.c
> +++ b/init/init_task.c
> @@ -184,6 +184,7 @@ struct task_struct init_task __aligned(L1_CACHE_BYTES) = {
> .vtime.state = VTIME_SYS,
> #endif
> #ifdef CONFIG_NUMA_BALANCING
> + .numa_preferred_nid_force = NUMA_NO_NODE,
> .numa_preferred_nid = NUMA_NO_NODE,
> .numa_group = NULL,
> .numa_faults = NULL,
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 79692f85643f..7d1532f35d15 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7980,7 +7980,10 @@ void sched_setnuma(struct task_struct *p, int nid)
> if (running)
> put_prev_task(rq, p);
>
> - p->numa_preferred_nid = nid;
> + if (p->numa_preferred_nid_force != NUMA_NO_NODE)
> + p->numa_preferred_nid = p->numa_preferred_nid_force;
> + else
> + p->numa_preferred_nid = nid;
>
> if (queued)
> enqueue_task(rq, p, ENQUEUE_RESTORE | ENQUEUE_NOCLOCK);
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> index 56ae54e0ce6a..4cba21f5d24d 100644
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -1154,6 +1154,7 @@ static void sched_show_numa(struct task_struct *p, struct seq_file *m)
> P(mm->numa_scan_seq);
>
> P(numa_pages_migrated);
> + P(numa_preferred_nid_force);
> P(numa_preferred_nid);
> P(total_numa_faults);
> SEQ_printf(m, "current_node=%d, numa_group_id=%d\n",
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 0c19459c8042..79d3d0840fb2 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2642,9 +2642,15 @@ static void numa_migrate_preferred(struct task_struct *p)
> unsigned long interval = HZ;
>
> /* This task has no NUMA fault statistics yet */
> - if (unlikely(p->numa_preferred_nid == NUMA_NO_NODE || !p->numa_faults))
> + if (unlikely(p->numa_preferred_nid == NUMA_NO_NODE))
> return;
>
> + /* Execute rest of function if forced PNID */
This comment had me confused, expecially since you check for
NUMA_NO_NODE and exit right after. Move it to after please.
> + if (p->numa_preferred_nid_force == NUMA_NO_NODE) {
> + if (unlikely(!p->numa_faults))
> + return;
> + }
> +
I am in two minds with this one here -> Why the unlikely for
p->numa_faults, and can we just make it one single if function?
> /* Periodically retry migrating the task to the preferred node */
> interval = min(interval, msecs_to_jiffies(p->numa_scan_period) / 16);
> p->numa_migrate_retry = jiffies + interval;
> @@ -3578,6 +3584,7 @@ void init_numa_balancing(unsigned long clone_flags, struct task_struct *p)
>
> /* New address space, reset the preferred nid */
> if (!(clone_flags & CLONE_VM)) {
> + p->numa_preferred_nid_force = NUMA_NO_NODE;
> p->numa_preferred_nid = NUMA_NO_NODE;
> return;
> }
> @@ -9301,7 +9308,11 @@ static long migrate_degrades_locality(struct task_struct *p, struct lb_env *env)
> if (!static_branch_likely(&sched_numa_balancing))
> return 0;
>
> - if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
> + /* Execute rest of function if forced PNID */
Same here.
> + if (p->numa_preferred_nid_force == NUMA_NO_NODE && !p->numa_faults)
> + return 0;
> +
> + if (!(env->sd->flags & SD_NUMA))
> return 0;
>
> src_nid = cpu_to_node(env->src_cpu);
> --
> 2.43.5
>
>
next prev parent reply other threads:[~2025-06-10 18:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 1:35 [PATCH 1/2] sched/numa: Add ability to override task's numa_preferred_nid Chris Hyser
2025-04-15 1:35 ` [PATCH 2/2] sched/numa: prctl to set/override " Chris Hyser
2025-04-16 7:00 ` [PATCH 1/2] sched/numa: Add ability to override " Madadi Vineeth Reddy
2025-04-16 21:13 ` Chris Hyser
2025-04-17 3:39 ` Madadi Vineeth Reddy
2025-06-10 18:31 ` Dhaval Giani [this message]
2025-06-11 15:12 ` Chris Hyser
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=aEh57Evd4WmrrvJx@fedora \
--to=dhaval@gianis.ca \
--cc=chris.hyser@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@techsingularity.net \
--cc=peterz@infradead.org \
/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.