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

[Andrew Morton <akpm@linux-foundation.org>]

On Thu,  6 Aug 2026 17:09:31 +0900 Rakie Kim <rakie.kim@sk.com> wrote:

> Package-aware weighted interleave places a task's weighted-interleave
> pages on the NUMA nodes of its local package, so that interleave traffic
> does not have to cross the interconnect to another package. This keeps
> each node's weight aligned with the bandwidth the task actually gets
> from it, so effective bandwidth holds up on a system that has more than
> one package. (A package is a CPU socket together with the memory
> attached to it.)

"package" is not a familiar term in MM.  It would be helpful if the
[0/N] were to carefully and fully define/describe the new term before
using it 40 times!

> Measured results:
> 
> System Configuration:
> - Processor: Dual-Socket Intel Xeon 6980P (Granite Rapids)
> 
> 1) Throughput (System Bandwidth)
>    - DRAM Only: 966 GB/s
>    - Weighted Interleave: 903 GB/s (7% decrease compared to DRAM Only)
>    - Package-Aware Weighted Interleave: 1329 GB/s (1.33 TB/s)
>      (38% increase compared to DRAM Only,
>       47% increase compared to Weighted Interleave)
> 
> 2) Loaded Latency (Under High Bandwidth)
>    - DRAM Only: 544 ns
>    - Weighted Interleave: 545 ns
>    - Package-Aware Weighted Interleave: 436 ns
>      (20% reduction compared to both)

Well that sounds nice.

>  .../ABI/testing/sysfs-devices-system-package  |   35 +
>  ...fs-kernel-mm-mempolicy-weighted-interleave |   17 +
>  drivers/cxl/core/region.c                     |   54 +
>  drivers/cxl/cxl.h                             |    1 +
>  drivers/dax/kmem.c                            |    3 +
>  include/linux/memory-tiers.h                  |  113 ++
>  include/linux/numa.h                          |   11 +
>  mm/memory-tiers.c                             | 1009 +++++++++++++++++
>  mm/mempolicy.c                                |  200 +++-

Are some user-facing Documentation/ updates appropriate?

The Documentation/ABI things are rather dry and information-free.  How
about some documentation for the operator who is wondering "should I
use this and if so why and how"?


The runtime sysfs on/off tunable is interesting.  I hear from google
operations people that every new feature should have such an "off"
switch so that if development send them a new thing and they think it's
problematic, they can disable it in order to quickly get back to the
old regime.  Perhaps that was your motivation, perhaps not.  Can you
please describe?


I see you've been emailed the Sashiko report, which appears substantial.
	https://sashiko.dev/#/patchset/20260806080936.421-1-rakie.kim@sk.com