Reproducing a memory pressure bug usually means filling RAM and hoping the kernel takes the path you care about. A request for comments from Juan Yescas at Google, posted on August 6, 2026, proposes a more precise instrument. Page Alloc Hogger exposes a DebugFS interface that allocates pages from a specific NUMA node, zone, migration type and allocation order, which lets you aim pressure at one part of the allocator instead of the whole machine. The stated goal is to trigger and inspect direct reclaim, kswapd, the OOM killer and allocation fallbacks without writing a custom driver for each experiment. It is a debugging aid, not a production feature.
The short answer
Juan Yescas of Google posted a request for comments on August 6, 2026 proposing Page Alloc Hogger, a DebugFS interface that allocates memory pages from a chosen node, zone, migration type and order. The point is precision: instead of filling memory and hoping the kernel takes the path you care about, you aim pressure at one corner of the allocator. It is meant for triggering direct reclaim, kswapd, the OOM killer and allocation fallbacks on demand. Explicitly a testing and debugging aid, not something to run in production.
Anyone who has chased a bug that only appears when a machine runs short of memory knows the shape of the problem. The bug is real, the report is credible, and the conditions refuse to come back on demand. You allocate until something gives, the kernel reclaims from somewhere unrelated, and the path you actually wanted to exercise never runs.
A patch series posted on August 6 by Juan Yescas of Google proposes a more precise instrument for that job. Page Alloc Hogger adds a DebugFS interface that allocates pages with the allocator parameters spelled out, which turns a blunt stress test into something closer to a reproduction.
Pressure you can point at something
The page allocator does not treat memory as one pool, and the reason bugs are hard to reproduce is that the distinctions matter.
A request carries a NUMA node, which on a multi socket machine determines which CPU package the memory is attached to. It carries a zone, a subdivision that exists because some hardware can only address part of the address space, which is why DMA, DMA32 and Normal are kept apart. It carries a migration type, the kernel's grouping of pages by how movable they are, which is the main defence against fragmentation. And it carries an order, the size as a power of two pages, where order zero is one page and order nine is two megabytes.
A userspace program that allocates in a loop chooses none of those. Page Alloc Hogger takes all four as parameters.
Why the tool being in the kernel matters
There is a practical reason this is not a userspace utility, and it is easy to miss.
If the thing applying memory pressure is an ordinary process, it is also a candidate for the OOM killer. Frequently it is the best candidate, since it is the largest consumer on the machine by a wide margin. So the experiment ends by killing the tool running the experiment, at exactly the moment the behaviour under study begins. Allocating from kernel context removes that, and the pressure stays until you release it.
The behaviours it exposes
The kernel has a set of mechanisms that only run when memory is short, and they are difficult to study for the same reason they are important.
Direct reclaim is the one most likely to be behind a complaint you have received. When an allocation cannot be satisfied, the allocating task goes and frees memory itself before continuing. The application does not see an error, it sees a pause, which is why this tends to arrive as a latency report rather than a memory report. Kswapd is the background version, reclaiming ahead of demand so that direct reclaim is not needed, and the gap between the two is where a lot of tuning happens.
The OOM killer is the end of the line, and its decisions are a recurring source of arguments. Allocation fallbacks are quieter: when the preferred zone or migration type cannot supply a request, the allocator takes memory from somewhere less suitable, and repeated fallbacks are how fragmentation turns into measurable slowdown.
Yescas frames the value as being able to trigger and inspect exactly these, plus unit testing memory management code and evaluating how an application behaves under severe constraint.
What it is not
It is not a production tool, and the RFC says so directly. It lives in DebugFS, which plenty of hardened systems do not mount at all, and its function is to consume memory that nothing will ever use.
It is also not merged. This is a request for comments, the earliest formal stage a kernel proposal reaches, and the label is a request for design feedback rather than review of finished work. A meaningful share of RFC series change shape or never land, and memory management attracts more scrutiny than most subsystems because the cost of getting it wrong is high. There is no target release.
What we would do with it
If you write kernel code that touches allocation, this is straightforwardly useful and the mailing list is where to say so while the interface is still open to change.
If you do not, the interesting audience is narrower than it first appears but real: people whose memory budget is fixed and tight. Embedded and mobile work lives there permanently, and so does anyone sizing containers against limits rather than against available RAM. Being able to put a machine into a specific low memory state and keep it there is a better test than filling memory and watching what happens, because the second one tests a condition you cannot describe afterwards.
For everyone else this is worth filing away rather than acting on. It is early, the interface will likely move, and the value arrives when it lands in a kernel you already run.
Sources and further reading
- Page Alloc Hogger lets you better stress memory behavior on Linux for testing and debugging, Phoronix, August 6, 2026
- The Page Alloc Hogger RFC patch series, Juan Yescas, kernel mailing list
- Kernel documentation on memory allocation
- Kernel documentation on physical memory and zones
Frequently asked questions
How is this different from just running stress-ng or a program that allocates a lot?
The difference is aim. A userspace program that allocates until something breaks applies pressure to the machine as a whole, and what the kernel does about it depends on which allocations happen to be in flight. You get pressure, but you do not choose the shape of it, and the interesting behaviour is often specific: an allocation of a particular order failing in a particular zone on a particular node. Page Alloc Hogger allocates from inside the kernel and takes the node, zone, migration type and order as parameters, so the pressure lands where you point it. There is a second difference that matters for debugging. Userspace allocations are subject to the OOM killer, so the tool applying the pressure can be the process that gets killed, which ends the experiment at the moment it becomes interesting. Kernel side allocations do not have that problem.
What do node, zone, migration type and order actually select?
They are the four axes the page allocator uses to decide where a page comes from. The node is the NUMA node, which on a multi socket server means which CPU package the memory is attached to and therefore how expensive it is to reach. The zone is a range within a node, and the historical reason it exists is hardware constraints: some devices can only address low memory, so the kernel keeps zones like DMA, DMA32 and Normal separate rather than treating memory as one pool. The migration type describes how movable a page is, which is what the kernel uses to fight fragmentation by grouping movable allocations together so they can be compacted later. The order is the size, as a power of two pages, so order zero is a single page and order nine is a two megabyte block. Being able to fix all four is what turns a stress test into a reproduction.
Which kernel behaviours does this let me observe?
The ones that only run when memory is short, which is precisely why they are hard to study. Direct reclaim is what happens when an allocation cannot be satisfied and the allocating task has to go free memory itself before it can continue, which shows up as latency in the application rather than as an error. Kswapd is the background counterpart, reclaiming ahead of demand so that direct reclaim is not needed. The OOM killer is the last resort when reclaim cannot keep up. Allocation fallbacks are what happens when the preferred zone or migration type cannot supply the request and the allocator takes memory from somewhere less ideal, which is the mechanism behind a lot of fragmentation related slowdowns. All four are documented and all four are difficult to trigger deliberately, which is the gap the patches are aimed at.
Is this something I would run on a production server?
No, and the proposal is explicit that it is not for end users. It lives in DebugFS, which is already a filesystem that many hardened configurations do not mount, and its entire purpose is to consume memory that nothing will use. Running it on a production system means deliberately creating the conditions you spend your time preventing. The realistic places for it are a test machine, a virtual machine you can discard, or a continuous integration job that verifies memory management behaviour before a change ships. The audience is people writing or debugging kernel code, plus people who need to test how an application behaves under genuine memory constraints, which is a real need for embedded and mobile work where the memory budget is fixed and tight.
What is the status, and when could it land?
It is a request for comments, which is the earliest formal stage a kernel proposal has. An RFC signals that the author wants design feedback rather than review of a finished patch, and a significant share of RFC series change substantially or never merge at all. Nothing here is queued for a release, and there is no target version. Memory management patches also tend to attract careful scrutiny, because the subsystem is one where a mistake is expensive and the maintainers are correspondingly conservative about new interfaces. The practical reading is that this is worth knowing about if you debug memory behaviour, worth following on the mailing list if you have an opinion on the interface, and not worth planning around yet.