From: Gregory Price <gourry@gourry.net>
To: Li Zhe <lizhe.67@bytedance.com>
Cc: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org,
joshua.hahnjy@gmail.com, ziy@nvidia.com, mingo@redhat.com,
peterz@infradead.org, mgorman@suse.de, riel@redhat.com,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, vschneid@redhat.com, kprateek.nayak@amd.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 1/6] sched/numa: clear fault locality state on execve
Date: Wed, 14 Oct 2026 09:02:45 -0400 [thread overview]
Message-ID: <as98SA5yfBaeI4oj@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <20261014094347.99157-2-lizhe.67@bytedance.com>
On Wed, Oct 14, 2026 at 05:43:42PM +0800, Li Zhe wrote:
> task_numa_free(p, false) is used by execve() to reset NUMA balancing
> state without freeing p->numa_faults, because concurrent readers may
> still observe the task.
>
Is a process that exec()'s going to run long enough to actually collect
any real numa fault data?
> the retained p->numa_faults array, but leaves the current-window buffer
> half and p->numa_faults_locality unchanged. Those are also NUMA fault
> feedback consumed by task_numa_placement() and update_task_scan_period(),
> so a newly executed image can inherit stale fault feedback from the old
> image.
I'm not sure this actually corrects much unless you have a long running
program that eventually exec()'s - and even then it seems like this all
self-corrects within a couple seconds.
Do you have some clear reproduction that makes an obvious wrong effect,
or was this just some static analysis?
It's "not wrong", but I'm trying to understand what impact this actually
has.
> The non-final path clears p->total_numa_faults and the averaged half of
>
> Clear the whole retained p->numa_faults array and p->numa_faults_locality
> together in the non-final reset path.
>
> Fixes: 04bb2f947505 ("sched/numa: Adjust scan rate in task_numa_placement")
> Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
> ---
> kernel/sched/fair.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 57360f5cdde4..1053437933ee 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4177,8 +4177,9 @@ void task_numa_free(struct task_struct *p, bool final)
> kfree(numa_faults);
> } else {
> p->total_numa_faults = 0;
> - for (i = 0; i < NR_NUMA_HINT_FAULT_STATS * nr_node_ids; i++)
> - numa_faults[i] = 0;
> + memset(p->numa_faults_locality, 0, sizeof(p->numa_faults_locality));
> + memset(numa_faults, 0, sizeof(*numa_faults) *
> + NR_NUMA_HINT_FAULT_BUCKETS * nr_node_ids);
> }
> }
>
> --
> 2.20.1
next prev parent reply other threads:[~2026-10-14 13:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 9:43 [PATCH 0/6] sched/numa: fix several NUMA balancing issues Li Zhe
2026-10-14 9:43 ` [PATCH 1/6] sched/numa: clear fault locality state on execve Li Zhe
2026-10-14 13:02 ` Gregory Price [this message]
2026-10-14 9:43 ` [PATCH 2/6] sched/numa: fix scan-period ratio denominator checks Li Zhe
2026-10-14 12:56 ` Gregory Price
2026-10-14 9:43 ` [PATCH 3/6] sched/numa: fix scan-period adjustment for shared faults Li Zhe
2026-10-14 13:12 ` Gregory Price
2026-10-14 9:43 ` [PATCH 4/6] sched/numa: make free-space tiering promotion bypass configurable Li Zhe
2026-10-14 13:16 ` Gregory Price
2026-10-14 9:43 ` [PATCH 5/6] sched/numa: do not feed tiering promotions into task placement stats Li Zhe
2026-10-14 13:26 ` Gregory Price
2026-10-14 9:43 ` [PATCH 6/6] sched/numa: ignore preferred nodes without normal balancing Li Zhe
2026-10-14 13:30 ` Gregory Price
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=as98SA5yfBaeI4oj@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=bsegall@google.com \
--cc=david@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=joshua.hahnjy@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=ljs@kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=rostedt@goodmis.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=ziy@nvidia.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