DAMOS_SPLIT splits large folios in a target region down to a
configured target order, using the existing split_folio_to_order().
No new core-mm code or exported symbols are introduced.
Based on mm-unstable at 61cccb8363fc ("mm/swap, PM: hibernate:
atomically replace hibernation pin").
Different addresses within a PMD-mapped folio resolve to the same
PMD Accessed bit. Accesses to a small part of the folio can
therefore coarsen DAMON's observed hot set relative to the actual
working set.
DAMOS already provides promotion actions (HUGEPAGE, COLLAPSE) but
has no corresponding demotion action. DAMOS_SPLIT fills this gap.
It is a mechanism, not a policy -- it does not decide which folios
to split. Selection is left to DAMON's existing access patterns,
filters, and future probe/PMU signals.
target_order selects the split target: 0 for order-0 base pages,
or a supported smaller mTHP order. Both anonymous and file-backed
folios are supported. The locking follows split_huge_pages_in_pid()
in mm/huge_memory.c.
Tests
=====
damos_split.py (VM + Kunpeng 920):
anon THP -> order-0 split: PASS
sangfor_exp.py (Kunpeng 920, tmpfs, 4096 MiB):
- Created a 4 GiB PMD-mapped tmpfs workload.
- Applied DAMOS_SPLIT with target_order=0.
- ShmemPmdMapped dropped from 4194304 KiB to 0 in every round.
- Repeated for five rounds without functional failures.
The functional selftest (damos_split.py) is included in this series.
Additional experiment scripts and raw results are available on
request. Performance characterization using masim [1] and KMB [2]
is in progress.
[1] https://github.com/sjp38/masim
[2] https://gitee.com/OpenCloudOS/kernel-multi-bench
Open questions
==============
- Selection policy: this series keeps folio selection outside the
action and relies on DAMOS access patterns, filters, and quotas.
Is this the appropriate layering for future probe-based signals?
- Hysteresis: khugepaged may re-collapse a just-split folio.
Should cooldown live in DAMON policy or khugepaged?
- File-backed folios: adjust target_order upward to filesystem
minimum, or keep current "fail and skip"?
Beyond the action API itself, feedback on real workloads that need
proactive large-folio demotion is particularly welcome. Follow-up
work will evaluate candidate selection signals, including DAMON
probes and hardware-assisted sampling, as well as target-order
selection and split/collapse hysteresis. Those policies are
intentionally kept outside this series.
Changes since v2 [3]
====================
- Split-only series (collapse deferred).
- Dropped SPE feedback (mechanism/policy separation).
- DAMOS_MTHP_SPLIT -> DAMOS_SPLIT.
- order field in existing union (no struct size increase).
- Added functional selftest (damos_split.py).
- checkpatch: 0 errors, 0 warnings.
[3] https://lore.kernel.org/[email protected]/
Lian Wang (Processmission) (3):
mm/damon: introduce DAMOS_SPLIT action
mm/damon/vaddr: implement DAMOS_SPLIT handler
selftests/damon: add functional test for DAMOS_SPLIT
.../ABI/testing/sysfs-kernel-mm-damon | 7 ++
Documentation/mm/damon/design.rst | 5 +
include/linux/damon.h | 15 ++-
mm/damon/core.c | 2 +
mm/damon/sysfs-schemes.c | 48 +++++++
mm/damon/vaddr.c | 90 +++++++++++++
tools/testing/selftests/damon/Makefile | 1 +
tools/testing/selftests/damon/_damon_sysfs.py | 9 +-
tools/testing/selftests/damon/damos_split.py | 99 +++++++++++++++
tools/testing/selftests/damon/sysfs.py | 11 +-
10 files changed, 279 insertions(+), 8 deletions(-)
