On Mon, 17 Aug 2026 12:19:51 -0400 Gregory Price <[email protected]> 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/[email protected]/ 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/[email protected]/ 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
