[LSF/MM/BPF TOPIC] Discussion: Targeted memory allocation via debugfs

[Juan Yescas <jyescas@google.com>]

Hi LSF MM organizers

I would like to propose a discussion on improving our ability to
reproduce complex memory allocation and reclaim scenarios, and solicit
feedback on a debugfs-based testing interface to help trigger these
edge cases.

== The Problem ==

We frequently encounter complex memory management issues in the wild, including:

- CMA allocation failures due to pinned MIGRATE_MOVABLE pages.
- Page migration and compaction failing during reclaim.
- Excessive reclaim loops triggered by specific workloads.
- OOM kills.

Reproducing these specific memory states for debugging is currently
cumbersome. For instance, consuming most of the available
MIGRATE_MOVABLE memory, or forcing MIGRATE_UNMOVABLE allocations
specifically from Node 1 and Zone DMA directly from userspace,
requires writing custom kernel modules or relying on unreliable
userspace memory pressure tactics.

== Proposed Approach ==

To simplify reproducer setups, we are exploring a debugfs driver that
allows us to perform highly targeted allocations using a
straightforward path-based API. The interface exposes the node, zone,
order, and migrate type.

Example 1: Allocating 2^11 pages from Node 1, Zone Normal, MIGRATE_MOVABLE


$ echo 1 > /sys/kernel/debug/mm/node-1/zone-Normal/order-11/migrate-Movable/alloc

This generates a unique handle (file) for the allocation:

$ ls /sys/kernel/debug/mm/node-1/zone-Normal/order-11/migrate-Movable/
8343cb1e-cc57-4753-a060-e152e0584e36

Example 2: Allocating 2^3 pages from Node 0, Zone DMA, MIGRATE_UNMOVABLE

$ echo 1 > /sys/kernel/debug/mm/node-0/zone-DMA/order-3/migrate-Unmovable/alloc

this gives

$ ls /sys/kernel/debug/mm/node-0/zone-DMA/order-3/migrate-Unmovable/
b5f607ec-eae3-4aca-b8ab-4335a4338a1f

To release the memory, userspace simply writes 0 to the generated handle:

$ echo 0 > /sys/kernel/debug/mm/node-0/zone-DMA/order-3/migrate-Unmovable/b5f607ec-eae3-4aca-b8ab-4335a4338a1f

== Discussion Points ==

Rather than presenting this as a finalized driver, I would like to use
this session to discuss the design with the mm community:

- API Semantics: Does this path-based structure make sense for
targeted allocations? How should we handle metadata (e.g., cating the
generated file to show allocation details/status)?

- Extensibility: What other memory shaping or fault-injection
functionality would be valuable to add to this driver for the broader
community?

- Alternative Approaches: Are there better existing mechanisms to
achieve this level of deterministic, user-controlled page allocation
for testing?

Thanks
Juan