From: Hongling Zeng <zhongling0719@126.com>
To: Zhan Xusheng <zhanxusheng1024@gmail.com>,
zenghongling@kylinos.cn, mingo@redhat.com, peterz@infradead.org,
juri.lelli@redhat.com, vincent.guittot@linaro.org,
dietmar.eggemann@arm.com, rostedt@goodmis.org,
bsegall@google.com, mgorman@suse.de, vschneid@redhat.com,
kprateek.nayak@amd.com
Cc: linux-kernel@vger.kernel.org, zhanxusheng@xiaomi.com
Subject: Re: [PATCH] sched/numa: Fix scan period for remote private faults
Date: Tue, 04 Aug 2026 14:07:48 +0800 [thread overview]
Message-ID: <6A7181B4.8030807@126.com> (raw)
In-Reply-To: <20260804034423.3786720-1-zhanxusheng@xiaomi.com>
在 2026年08月04日 11:44, Zhan Xusheng 写道:
> From: Zhan Xusheng <zhanxusheng1024@gmail.com>
>
> On Tue, Aug 04, 2026 at 11:07:31AM +0800, Hongling Zeng wrote:
>> This is wrong because for remote private memory, we should continue
>> to the ratio calculation which can speed up scanning to migrate the
>> memory to the local node.
> I don't think the ratio calculation actually speeds scanning up in that
> case, though. For the pure remote-private accesses you describe
> (shared == 0, private > 0):
>
> ps_ratio = private * NUMA_PERIOD_SLOTS / (private + shared)
> = private * 10 / (private + 0)
> = 10
>
> which is >= NUMA_PERIOD_THRESHOLD (7), so it takes the first branch:
>
> int slot = ps_ratio - NUMA_PERIOD_THRESHOLD; /* 3 */
> diff = slot * period_slot; /* > 0 */
>
> and numa_scan_period is *increased* (scan slower), not decreased. The
> speed-up (else) branch is only reached when both ps_ratio < 7 and
> lr_ratio < 7, which pure-private accesses (ps_ratio == 10) never satisfy.
>
> So dropping the early return here doesn't speed scanning up; it just
> grows the period by ~3 slots instead of doubling it. That might still be
> a reasonable change, but the justification as written describes an effect
> that doesn't seem to happen. Could you double-check, and share some
> before/after numbers on a remote-private workload? A scan-rate change
> like this really wants data behind it.
Thank you for the detailed review. Your analysis is completely correct.
You're right. The original commit message incorrectly claimed this would
"speed up" scanning. The actual effect is changing from unconditional
doubling to a ratio-based adjustment (which still slows scanning, but
less
aggressively).
I've updated the patch based on your feedback:
[PATCH v2] sched/numa: avoid doubling scan period for remote private faults
>
> Two smaller things:
>
> - The comment rewrites (ps_ratio -> "private", lr_ratio -> "local") look
> like a reasonable cleanup on their own, but folding them into a
> behavioural change makes the patch harder to review -- perhaps split
> them out. (The lr_ratio branch also keeps the "shared ... moved by
> other tasks" sentence, which no longer fits a local-dominant branch.)
This is a good point. For now I've kept them together since both changes
address the same underlying issue (misleading comments about what the
ratios
represent). If this version is acceptable, I can submit a separate
cleanup
patch in the future if needed.
>
> - This is the same early return that other in-flight patches touch (the
> numa_faults_locality reset thread, where Peter suggested sharing the
> tail with the normal path). It may be worth coordinating so the
> changes don't collide
>
> Thanks,
> Zhan Xusheng
I'll check for coordination with other in-flight patches before the next
submission.
Thank you again for catching the fundamental issue with the original
justification and for the detailed suggestions on how to improve it.
Best regards,
Hongling
prev parent reply other threads:[~2026-08-04 6:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 3:07 [PATCH] sched/numa: Fix scan period for remote private faults Hongling Zeng
2026-08-04 3:44 ` Zhan Xusheng
2026-08-04 6:07 ` Hongling Zeng [this message]
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=6A7181B4.8030807@126.com \
--to=zhongling0719@126.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 \
--cc=zenghongling@kylinos.cn \
--cc=zhanxusheng1024@gmail.com \
--cc=zhanxusheng@xiaomi.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 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.