Topic selectiontopic-selection/proposals/B-khugepaged-collapse-creep
Proposal B — Collapse creep: when khugepaged undoes its own work
Angle A with a characterization spine · Compute 0 · Kernel 3 · ML 1 · ~6–9 months full-time-equivalent · workshop ceiling
Literature verified 26 August 2026. The evidence that this area is open rests partly on absence of search hits, which is the weakest kind of evidence and is called out explicitly below. Re-verify before committing.
This document is the Phase 0 deliverable described in guide/01-scoping.md. Compress it to
one page before you send it to your advisor.
The problem, and who has it
khugepaged scans address space in the background looking for regions worth collapsing into
huge pages. Whether a region qualifies is governed by max_ptes_none: how many absent PTEs
the kernel will tolerate inside a candidate region and still fill them in.
Nico Pache's multi-size THP support for khugepaged (LWN 1034426,
at v17 in mm-unstable as of May 2026) documents a pathology it names collapse creep. Where
max_ptes_none exceeds HPAGE_PMD_NR/2, the collapse itself installs enough non-zero pages
that the next scan of the same region satisfies the promotion condition again. The region is
therefore re-collapsed at a larger order, and again, and the mTHP order ratchets upward
indefinitely — each step consuming compaction and khugepaged CPU, and each step inflating the
memory footprint with pages nobody asked for.
The maintainers' response was not to fix it. It was to forbid intermediate values of
max_ptes_none altogether, permitting only 0 or 511 and emitting a warning otherwise. A
tunable was disabled because its middle range could not be made to behave.
Who pays: any workload with a sparse address space where an intermediate threshold would be the correct policy, and where the compaction stalls and khugepaged CPU are charged against a latency-sensitive foreground session rather than a batch fleet.
Why it is hard — why the obvious solution fails
max_ptes_none=0 sidesteps creep entirely and costs nothing, so it is your baseline and it is
free. The whole thesis therefore depends on establishing something you have not yet
established: that max_ptes_none=0 forgoes real, measurable TLB benefit on some workload
class that matters. If it does not, the maintainers simply picked a good default and there
is nothing here. Establish this in Phase 1, not month six.
The deeper reason a static threshold cannot work is the interesting part, and it is what makes this a research question rather than a tuning exercise. A scalar fullness threshold has no way to distinguish a collapse that will be retained from one that will be immediately re-collapsed or split. Those two cases look identical at decision time and have opposite value. That is a prediction problem, not a threshold problem — and it is the same shape as PACT's finding one subsystem over, that access frequency is the wrong signal for tiered memory and per-page stall criticality is the right one.
Why now
mTHP collapse is landing right now, at v17, which means the policy slot is open and being filled by hand as you read this. And unusually for this repository, the limitation is documented by the maintainers themselves rather than inferred by you from a limitations section. You are not arguing that a problem exists; you are arguing that the workaround for a conceded problem is leaving value on the table.
The adjacent machinery is also moving: Usama Arif's large-folio readahead series for exec memory reached v7 by June 2026 (LWN 1064021, LWN 1066175), building exactly the "large folios for a big read-only mapping, adapting under pressure" infrastructure that a collapse-policy thesis would sit beside.
Thesis statement
By predicting collapse retention from per-region access sparsity and recent collapse history rather than from a static fullness threshold, an online per-order gating policy inside khugepaged recovers more than half of the TLB benefit that
max_ptes_none=0forgoes on sparse-address-space workloads, while keeping khugepaged CPU time and compaction stalls within 20% of themax_ptes_none=0baseline.
Placeholders until Phase 1. Note that the cost bound is inside the claim, which for an Angle A
topic is mandatory rather than stylistic — guide/01-scoping.md is emphatic that the
incumbent heuristic here is not merely fast but nearly free.
Decomposed claims
| # | Claim | How you would know it is false |
|---|---|---|
| 1 | Collapse creep is quantifiable: at intermediate max_ptes_none, a substantial fraction of collapses are followed by re-collapse or split within a bounded number of scans | The churn fraction is negligible under real workloads, making the maintainers' restriction cost-free |
| 2 | max_ptes_none=0 forgoes measurable TLB benefit on sparse-address-space workloads | dTLB miss rates and end-to-end times at 0 match those at intermediate settings |
| 3 | A cheap online predictor gating collapse per order recovers a substantial share of that benefit without the churn | The predictor's accuracy is too low to act on, or its own cost inside khugepaged exceeds the benefit |
The gap, in one paragraph
This is an unvalidated assumption: that a static per-order fullness threshold can separate worthwhile collapses from creep. The evidence that the assumption fails is the maintainers' own decision to restrict the tunable rather than tune it. The closest works are the mTHP collapse series itself, which states the pathology and the workaround; xHeap (Malliotakis, Papagiannis, Marazakis, Bilas, CHEOPS '26, a refereed EuroSys-affiliated workshop), which lands the general critique that Linux THP under memory offloading is "overly aggressive in committing memory, and too coarse-grained" and that promotions "lack the responsiveness and concurrency necessary," achieving up to 15× fewer dTLB miss cycles with concurrent asynchronous promotions; and Temeraire (Hunter et al., OSDI '21), which a reviewer will cite as evidence that the hugepage-policy space is thoroughly worked. Ingens and HawkEye belong in the same paragraph.
Be honest about the evidence for openness. No ML or LLM work on huge-page collapse
decisions surfaced in 2024–2026. That is absence of hits, not proof, and this repository's own
../02-crowdedness-evidence.md records that every prior estimate moved toward more crowded.
Treat this rating as a lower bound and run the idea-killing afternoon against "hugepage
promotion policy," "page promotion prediction," and the Temeraire and Ingens citation graphs
before committing.
How you measure it
Kernel counters first, because they are cheap and they are what a reviewer will trust:
thp_collapse_alloc, thp_split_pmd, compact_stall, compact_fail, and khugepaged CPU
time. Then a matrix across enabled (always/madvise/never) × defrag
(always/defer/defer+madvise/madvise/never) × max_ptes_none, with dTLB miss rates
from the PMU and end-to-end workload latency percentiles. The churn measurement in claim 1 is
the novel instrument: you need per-region collapse history, which the existing counters do
not give you, so building that tracing is your Phase 1 deliverable.
What you build on
One bare-metal machine with an mTHP-capable kernel (6.13 or newer, and realistically a mm-unstable tree to get the v17 series). THP sysfs, PMU access, and tracepoints or a patched khugepaged. Very cheap to run and no GPU whatsoever.
Fallback
A characterization of collapse and split churn under real workloads is a contribution in its own right, and it is the artifact the maintainers would actually find useful — the restriction to 0 or 511 was made without published data on how bad the middle range is.
What must work by week eight
Per-region collapse-history tracing, the counter matrix automated to one command, and the
claim-2 result: does max_ptes_none=0 actually leave TLB benefit unclaimed? If it does not,
stop here and switch topics with ten months still in hand.
How it goes wrong
The tuning objection, which is the serious one. "This is a tuning problem and the maintainers already picked safe defaults." Your answer must be claim 2 with numbers attached. Without it, the thesis is a configuration note.
A moving target with sixteen rounds of prior opinion. v17 means the maintainers have
already argued through sixteen versions of this design, and you must absorb that discussion
before proposing anything, or you will re-propose something already rejected on the list.
Budget real time for reading linux-mm archives — this is not optional background, it is the
related-work chapter.
The skill mismatch, and this is the reason B is second rather than first. This is core memory-management work: instrumenting and probably patching khugepaged, building against mm-unstable, and debugging a subsystem where a mistake produces a machine that will not boot. Your self-assessment did not include reading kernel source confidently, patching and building custom kernels, or strong systems programming in C. Proposal A needs eBPF, which you have; proposal B needs the two skills adjacent to it that you do not yet. At six part-time months, acquiring them is most of your budget.
Rejection vocabulary: "known THP fragmentation behavior," "just use defer+madvise,"
"mTHP already addresses this," "Ingens," "HawkEye," "Temeraire," "this is a tuning problem."
Honest comparison against proposal A
| A: memory-hierarchy citizenship | B: collapse creep | |
|---|---|---|
| Kernel depth required | 2 — eBPF and struct_ops, which you have | 3 — instrumenting and patching core MM, which you do not |
| Evidence the gap is real | Named incumbents whose objective function differs from yours | Maintainers' own conceded limitation, but openness rests on absence of hits |
| Can it fail outright | No — the characterization is the result | Yes — if claim 2 is false there is nothing here |
| Ceiling | Workshop, plausibly a measurement conference | Workshop |
| Shelf life | ~1 year; BPF OOM and the zram fix are landing | Longer, but the design is being settled on linux-mm now |
| Departmental fit | Core MM, unambiguous | Core MM, unambiguous |
| Week-eight kill test | Cheap: run the cgroup baseline | Cheap: does max_ptes_none=0 forgo real benefit? |
Both have a cheap week-eight test that can kill them, which is the single most valuable property either one has. The difference that decides it is the kernel-depth row: B asks you to learn core-MM development on a part-time budget, and A asks you to use the one kernel skill you already have.
Venues
Workshop-scale: HotStorage, APSys, CHEOPS at EuroSys (where xHeap appeared, which makes it a
natural home), Linux Plumbers, or an mm-unstable-facing RFC. A measurement conference is
plausible if claim 1's churn numbers turn out to be dramatic.