From: Gregory Price <gourry@gourry.net>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org,
liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, mingo@redhat.com,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, dietmar.eggemann@arm.com,
rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de,
vschneid@redhat.com, kprateek.nayak@amd.com, ziy@nvidia.com,
baolin.wang@linux.alibaba.com, nico.pache@linux.dev,
ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org,
lance.yang@linux.dev, usama.arif@linux.dev, kas@kernel.org,
gourry@gourry.net, joshua.hahnjy@gmail.com, rakie.kim@sk.com,
ying.huang@linux.alibaba.com, matthew.brost@intel.com,
byungchul@sk.com, apopple@nvidia.com, jannh@google.com,
pfalcato@suse.de, hannes@cmpxchg.org, shy828301@gmail.com,
osalvador@suse.de, raghavendra.kt@amd.com
Subject: [PATCH v4 0/7] sched/numa: stop VMA scan filters from gating promotion
Date: Wed, 30 Sep 2026 07:21:59 -0400 [thread overview]
Message-ID: <20260930112206.205083-1-gourry@gourry.net> (raw)
NUMA balancing uses hinting faults for both task placement and
memory-tier promotion. Several filters designed to avoid unproductive
socket-placement faults also prevent promotion.
In a production deployment using kernel.numa_balancing=2 on a host
with 768 GB of DRAM and 256 GB of CXL memory running two ~430 GB
database workloads with large shmem VMAs - we discovered poor NUMA
balancing behavior:
Before patch series:
- 150-200 GB/s DRAM bandwidth
- 40-45 GB/s CXL bandwidth, saturating the device
- request latency above 5 ms with longer tails
After patch series:
- 250+ GB/s sustained DRAM bandwidth
- approximately 5-10 GB/s sustained CXL bandwidth
- request latency between 800 us and 2 ms
The core issue is that the global balancing mode says which mechanisms
are enabled, but it cannot describe the intent of an individual
VMA/PTE walk (placement vs promotion).
This plumbs the scan reasoning into the prot_none injection while
retaining the placement-scan filtering.
Patches 1-5 form the backportable fix set:
1. Add promotion-only NUMA protection walks and derive private VMA
state in the folio eligibility check.
2. Permit eligible shared folios to be promoted to a fast tier and
rename the promotion predicate to folio_numab_promotable().
3. Scan mappings covered by the legacy file placement filter using
promotion-only scans.
4. Separate VMA placement eligibility from partial-scan continuation.
5. Scan PID-inactive VMAs for promotion and account for placement scans
separately.
Patches 4 and 5 are technically part of the same fix, but are separated
to make it easier to review - they must be backported together.
Patches 6-7 are independently requested cleanups.
6. Use BIT() for the change_protection() flags.
7. Use the VMA flag API in the touched NUMA-balancing code.
Changes in v4:
- 1/7: commit message fix (David).
Hoist balancing mode check into variables.
- 2/7: Rename folio_in_lowtier() to folio_numab_promotable()
Typo fix.
- 3/7: Compute placement_scan once per VMA.
Avoid complex boolean logic (David)
Fix indentation (David).
- 4/7: Avoid complex boolean logic (David)
Store the in-progress state as numab_state->promo_only.
- 5/7: Avoid complex boolean logic (David).
Fix "sticky bit" issue where resumed scans would cause
valid VMAs to drop out of the scanning-eligible set.
v3: https://lore.kernel.org/r/20260922182928.2199090-1-gourry@gourry.net
Gregory Price (Meta) (7):
mm: support promotion-only NUMA hinting scans
mm: allow shared folios to be promoted to a fast tier
sched/numa: scan read-only file mappings in tiering mode
sched/numa: separate VMA placement from scan continuation
sched/numa: scan PID-inactive VMAs for promotion
mm: use BIT() for change_protection() flags
mm: use VMA flag helpers in NUMA balancing
include/linux/mm.h | 23 +++++----
include/linux/mm_types.h | 13 +++++
kernel/sched/fair.c | 100 ++++++++++++++++++++++++++++-----------
mm/huge_memory.c | 3 +-
mm/internal.h | 6 +--
mm/memory-tiers.c | 9 ++--
mm/memory.c | 2 +-
mm/mempolicy.c | 37 ++++++++-------
mm/migrate.c | 13 +++--
mm/mprotect.c | 7 +--
10 files changed, 140 insertions(+), 73 deletions(-)
--
2.55.0
next reply other threads:[~2026-09-30 11:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 11:21 Gregory Price [this message]
2026-09-30 11:22 ` [PATCH v4 1/7] mm: support promotion-only NUMA hinting scans Gregory Price
2026-09-30 11:22 ` [PATCH v4 2/7] mm: allow shared folios to be promoted to a fast tier Gregory Price
2026-10-01 10:34 ` David Hildenbrand (Arm)
2026-09-30 11:22 ` [PATCH v4 3/7] sched/numa: scan read-only file mappings in tiering mode Gregory Price
2026-10-01 10:34 ` David Hildenbrand (Arm)
2026-09-30 11:22 ` [PATCH v4 4/7] sched/numa: separate VMA placement from scan continuation Gregory Price
2026-10-01 10:44 ` David Hildenbrand (Arm)
2026-10-01 13:29 ` Gregory Price
2026-09-30 11:22 ` [PATCH v4 5/7] sched/numa: scan PID-inactive VMAs for promotion Gregory Price
2026-10-01 10:45 ` David Hildenbrand (Arm)
2026-09-30 11:22 ` [PATCH v4 6/7] mm: use BIT() for change_protection() flags Gregory Price
2026-09-30 11:22 ` [PATCH v4 7/7] mm: use VMA flag helpers in NUMA balancing Gregory Price
2026-10-01 10:45 ` David Hildenbrand (Arm)
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=20260930112206.205083-1-gourry@gourry.net \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bsegall@google.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=dietmar.eggemann@arm.com \
--cc=hannes@cmpxchg.org \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=juri.lelli@redhat.com \
--cc=kas@kernel.org \
--cc=kernel-team@meta.com \
--cc=kprateek.nayak@amd.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=nico.pache@linux.dev \
--cc=osalvador@suse.de \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=raghavendra.kt@amd.com \
--cc=rakie.kim@sk.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shy828301@gmail.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®