From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Gregory Price <gourry@gourry.net>
Cc: Li Zhe <lizhe.67@bytedance.com>,
akpm@linux-foundation.org, ljs@kernel.org, liam@infradead.org,
rppt@kernel.org, mhocko@suse.com, corbet@lwn.net,
skhan@linuxfoundation.org, ziy@nvidia.com,
joshua.hahnjy@gmail.com, ying.huang@linux.alibaba.com,
apopple@nvidia.com, linux-mm@kvack.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/numa_balancing: allow migrate on protnone reference with MPOL_WEIGHTED_INTERLEAVE policy
Date: Thu, 1 Oct 2026 12:55:12 +0200 [thread overview]
Message-ID: <e8e7bdef-8c12-47bb-8b39-54405b857156@kernel.org> (raw)
In-Reply-To: <ar0LqjO3-cwU6-Jy@gourry-fedora-PF4VCD3F>
On 9/30/26 15:40, Gregory Price wrote:
> On Wed, Sep 30, 2026 at 02:32:16PM +0200, David Hildenbrand (Arm) wrote:
>>>
>>> Right, but you're requesting this configuration. If you didn't set
>>> F_NUMA_BALANCING then you get the existing semantics.
>>>
>>> In the existing semantics, if we're INTERLEAVE and WEIGHTED_INTERLEAVE
>>> we just always say "no tiering for you".
>>>
>>> But as an opt-in option? I don't quite see the argument for saying
>>> interleaved regions (or tasks) to be opted-out if the user asks for it -
>>> that just seems like an arbitrary limitation.
>>
>> Just to be clear, what I am saying is: the proposed semantics are inconsistent
>> (weighted when mechanism A honors them and mechanism B doesn't honor them), but
>> once we set these semantics in stone like that, we cannot easily change them
>> later because some user might depend on that behavior.
>>
>> So you'll need yet another flag to say "NUMA balancing really also honors the
>> weights". And that's where it all gets ugly.
>>
>
> I would agree with you if demotion didn't entirely ignoring mempolicy.
>
> On a tiered system, mempolicy *only* applies to initial (or fault-in)
> placement, and otherwise is more or less entirely ignored. This is
> a case where it's not ignored - which is actually inconsistent with
> the rest of the tiering tools (demotion, damon).
>
> This is why I said this distinction may only make sense in TIERING
> mode, while in NORMAL mode you likely just want to fault it back to
> its original interleave location.
>
> Also file interleave (indexed by offset) vs task (counter-incremented)
> policies are affected by these changes very differently, which I asked
> for some thought on.
>
> As tiering develops, the less I think task-mempolicy as a whole makes
> much sense (because it's at-best advisory).
Fully agreed to that. I even struggle to understand how an initial placement
using the weighted policy really fits into that picture.
--
Cheers,
David
prev parent reply other threads:[~2026-10-01 10:55 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 7:26 [PATCH] mm/numa_balancing: allow migrate on protnone reference with MPOL_WEIGHTED_INTERLEAVE policy Li Zhe
2026-09-30 8:43 ` Gregory Price
2026-09-30 8:59 ` Li Zhe
2026-09-30 9:11 ` Gregory Price
2026-09-30 10:59 ` Joshua Hahn
2026-09-30 11:22 ` Li Zhe
2026-09-30 12:25 ` Gregory Price
2026-10-02 7:25 ` Li Zhe
2026-09-30 11:26 ` David Hildenbrand (Arm)
2026-09-30 11:52 ` Li Zhe
2026-09-30 12:11 ` Joshua Hahn
2026-09-30 14:02 ` Li Zhe
2026-09-30 14:50 ` Gregory Price
2026-09-30 15:10 ` Zi Yan
2026-10-01 10:54 ` David Hildenbrand (Arm)
2026-10-01 11:18 ` Zi Yan
2026-10-01 13:26 ` Gregory Price
2026-10-02 7:56 ` David Hildenbrand (Arm)
2026-10-02 8:15 ` Li Zhe
2026-10-02 12:05 ` Gregory Price
2026-09-30 12:03 ` Gregory Price
2026-09-30 12:32 ` David Hildenbrand (Arm)
2026-09-30 13:40 ` Gregory Price
2026-10-01 10:55 ` David Hildenbrand (Arm) [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=e8e7bdef-8c12-47bb-8b39-54405b857156@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=corbet@lwn.net \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=liam@infradead.org \
--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=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=ying.huang@linux.alibaba.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 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.