Re: [PATCH 0/4] mm/mempolicy: introduce package-aware weighted interleave

[Rakie Kim <rakie.kim@sk.com>]

On Mon, 17 Aug 2026 12:19:51 -0400 Gregory Price <gourry@gourry.net> wrote:

> The original attempt to handle cross-socket interleave tried to deal
> with this with a matrix for weights, but this was deemed too invasive.
>
> This brings back that matrix, but not for per-node weights - we're
> basically just adding an addition weighting to filter on.

Yes. It uses additional information to filter the nodes weighted
interleave selects from.

> I have some concerns with the now additional filtering mechanism
> introdced into the allocation stack, but fundamentally I think this is
> a *better* solution than a straight weight-matrix.

About the cost of the filter: when the toggle is off, the filter does
not run. When it is on, node selection needs a nodemask filtering
step, but in my tests the overhead was negligible. I will look at
this part further and check whether there is more room to optimize.

> I will need to chew on this for a bit.  It seems there's non-trivial
> sashiko bug reports here to address anyway.

I am working on the sashiko findings now. The valid ones will be
fixed in the next version.

> When worded this way, "Package" sounds completely arbitrary and not a
> useful distinction.  This really just sounds like an extention for the
> existing fallback lists to take interconnects into account.

Other reviewers also pointed out that the "package" / "socket"
terminology is ambiguous. I think the description needs a full rework
so that it explains the current state better, and I plan to do that
in the next version.

> I wonder if abstract distance either:
>   1) already gives you what you want (the secondary weight)
>   2) can be twiddled in BIOS to give you what you want.

I thought about abstract distance a lot as well. My conclusion was
that adistance alone cannot tell whether nodes are in the same
package. This is an area I am still thinking about, and it needs
more thought.

About the BIOS information: as I reported before, on the two-package
server I tested, each package had its own CXL device, but the HMAT
reported one CPU node as the initiator of both CXL nodes:

https://lore.kernel.org/all/20260330025914.361-1-rakie.kim@sk.com/

I will post an update on that issue as well. What this series uses
is, in the end, BIOS information too. But some of that information
has errors and some of it looks reliable, so I think we also need to
sort out which is which, and understand why.

> The way this is written it sounds to me like this should just be the
> default weighted interleave behavior.  We already know weighted
> interleave does not jive well with multi-socket systems - this just
> fixes that (in a more general sense, Socket => Package).

I agree with your point. The default is off because it was requested
during the v1 review; Jonathan asked for it:

https://lore.kernel.org/all/20260325123350.00004d48@huawei.com/

Enabling is also not unconditional. I added a few constraints, so it
turns on only in a specific situation: when the packages have the
same node structure. I think the definition of these on/off
conditions is open, and it needs more discussion.

Thanks again for your time and review.

Rakie Kim