mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hui Su <sh_def@163.com>
To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
	vincent.guittot@linaro.org
Cc: dietmar.eggemann@arm.com, rostedt@goodmis.org,
	bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
	kprateek.nayak@amd.com, linux-kernel@vger.kernel.org
Subject: [PATCH] sched/numa: Fix time unit mismatch in scan staggering
Date: Thu, 27 Aug 2026 17:59:02 +0800	[thread overview]
Message-ID: <20260827095902.2645166-1-sh_def@163.com> (raw)

init_numa_balancing() stores node_stamp in nanoseconds, but
task_scan_max() and numa_scan_period are in milliseconds. The existing
min_t() compares task_scan_max() in milliseconds with a nanosecond
value, so it can initialize node_stamp far too small and defeat
staggering for new threads sharing an mm.

For example, with the default scan periods and two mm users, the
intended stagger is 2000 ms. The existing code instead computes a
60000 ns delay; after adding the two-tick offset, node_stamp is about
2.06 ms with HZ=1000.

Moreover, min_t() and delay use unsigned int, so nanosecond values above
UINT_MAX are truncated. On 32-bit systems, the multiplication can also
overflow before the value is converted.

Compare the delay in milliseconds using u64 and convert to nanoseconds
after the minimum is selected. This preserves the intended cap and keeps
node_stamp in the unit consumed by task_tick_numa().

This prevents NUMA balancing scans from being concentrated for
multithreaded workloads and avoids shortening the initial stagger
through integer truncation.

Fixes: 137844759843 ("sched/numa: Stagger NUMA balancing scan periods for new threads")
Signed-off-by: Hui Su <sh_def@163.com>
---
 kernel/sched/fair.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6d881e530f89..6924cf3b3a67 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4413,12 +4413,11 @@ void init_numa_balancing(u64 clone_flags, struct task_struct *p)
 	 * already by arch_dup_task_struct but stagger when scans start.
 	 */
 	if (mm) {
-		unsigned int delay;
+		u64 delay_ms;
 
-		delay = min_t(unsigned int, task_scan_max(current),
-			current->numa_scan_period * mm_users * NSEC_PER_MSEC);
-		delay += 2 * TICK_NSEC;
-		p->node_stamp = delay;
+		delay_ms = (u64)current->numa_scan_period * mm_users;
+		delay_ms = min_t(u64, delay_ms, task_scan_max(current));
+		p->node_stamp = delay_ms * NSEC_PER_MSEC + 2 * TICK_NSEC;
 	}
 }
 
-- 
2.54.0


                 reply	other threads:[~2026-08-27 10:00 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260827095902.2645166-1-sh_def@163.com \
    --to=sh_def@163.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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

all inboxes | Powered by JetHome®