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

[Gregory Price <gourry@gourry.net>]

On Thu, Aug 06, 2026 at 05:09:31PM +0900, Rakie Kim wrote:
> 
> To make this possible the kernel needs a notion of which nodes share a
> package. The NUMA distance model offers only relative latencies and no
> structural grouping, which is especially limiting for CXL memory nodes
> that come online without an explicit package association.
> 

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.

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.

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

> The series adds a package-aware topology layer that groups CPU and
> memory-only nodes into a "memory package", built from the physical
> package ids firmware reports and, for a memory-only node, an initiator
> CPU node or SLIT distances. A package can contain more than one CPU node
> or more than one memory-only node, so the layer maps a package to a set
> of nodes rather than to a single node or a single CXL device.
> 

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.

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.

> The feature is off by default and opt-in through a sysfs toggle. The
> package topology itself is exposed read-only under
> /sys/devices/system/package/; there is deliberately no writable
> override, since a machine whose firmware describes its topology
> incorrectly should be fixed in firmware. On a topology that does not
> have the symmetric shape the placement relies on, enabling is refused
> and any active mode degrades cleanly to the original flat behavior.

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).

~Gregory