mm/Kconfig.debug | 12 + mm/Makefile | 1 + mm/page_alloc_hogger.c | 610 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 623 insertions(+) create mode 100644 mm/page_alloc_hogger.c
This patch series introduces the Page Alloc Hogger. The Page Alloc Hogger allows you to allocate memory pages from specific nodes, zones, migration types, and orders directly via debugfs. This provides key benefits for testing and debugging: - Reproduce low-memory conditions: Easily trigger and inspect kernel mechanisms like direct reclaim, kswapd, the OOM killer, and allocation fallbacks. - Simplify memory pressure debugging: Debug issues that only manifest under memory stress without needing custom kernel drivers or userspace programs to allocate memory. - Simplify unit testing: Verify that memory management subsystems (direct reclaim, OOM killer, kswapd) trigger as expected in test suites. - Measure performance under stress: Evaluate how applications behave and perform during severe memory pressure. Usage: 1. To trigger the allocation, navigate to the debugfs path corresponding to your target node, memory zone, allocation order, and migration type, then write the requested allocation count to nr_pages_allocs. For example, to make 3 allocs of order 9, Migrate Type Movable, Zone Normal and Node 0, run: $ echo 3 > /sys/kernel/debug/mm/node-0/zone-Normal/order-9/migrate-Movable/nr_pages_allocs 2. For each allocation created, a corresponding file named sequentially (1, 2, n) will appear in that directory. $ ls /sys/kernel/debug/mm/node-0/zone-Normal/order-9/migrate-Movable/ 1 2 3 nr_pages_allocs 3. To free the allocation, write the allocation file name in /sys/kernel/debug/mm/free. For example, to release the 2nd allocation run: $ echo 2 > /sys/kernel/debug/mm/free Example: $ cat /proc/pagetypeinfo Page block order: 9 Pages per block: 512 Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 Node 0, zone DMA, type Unmovable 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type Movable 1 1 1 0 1 1 2 2 1 3 732 Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type CMA 0 0 0 0 0 0 0 0 0 1 7 Node 0, zone DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type Unmovable 13 7 0 1 0 0 1 0 1 0 0 Node 0, zone Normal, type Movable 1 1 1 1 1 1 1 0 1 1 1221 Node 0, zone Normal, type Reclaimable 1 0 0 0 0 0 1 0 0 1 0 Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type CMA 0 0 0 0 0 0 0 0 0 1 7 Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Number of blocks type Unmovable Movable Reclaimable HighAtomic CMA Isolate Node 0, zone DMA 0 1520 0 0 16 0 Node 0, zone Normal 12 2530 2 0 16 0 $ echo 1200 > /sys/kernel/debug/mm/node-0/zone-Normal/order-10/migrate-Movable/nr_pages_allocs $ cat /proc/pagetypeinfo Page block order: 9 Pages per block: 512 Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 Node 0, zone DMA, type Unmovable 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type Movable 1 1 1 0 1 1 2 2 1 3 732 Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type CMA 0 0 0 0 0 0 0 0 0 1 7 Node 0, zone DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type Unmovable 13 7 1 1 0 0 0 0 1 0 0 Node 0, zone Normal, type Movable 1 1 1 1 1 1 1 0 1 1 21 Node 0, zone Normal, type Reclaimable 0 1 0 0 1 0 0 0 1 0 0 Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type CMA 0 0 0 0 0 0 0 0 0 1 7 Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Number of blocks type Unmovable Movable Reclaimable HighAtomic CMA Isolate Node 0, zone DMA 0 1520 0 0 16 0 Node 0, zone Normal 12 2530 2 0 16 0 $ for i in `seq 1 1200`; do echo $i > /sys/kernel/debug/mm/free; done $ cat /proc/pagetypeinfo Page block order: 9 Pages per block: 512 Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10 Node 0, zone DMA, type Unmovable 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type Movable 1 1 1 0 1 1 2 2 1 3 732 Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone DMA, type CMA 0 0 0 0 0 0 0 0 0 1 7 Node 0, zone DMA, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type Unmovable 13 7 1 1 0 0 0 0 1 0 0 Node 0, zone Normal, type Movable 1 1 1 1 1 1 1 0 1 1 1221 Node 0, zone Normal, type Reclaimable 0 1 0 0 1 0 0 0 1 0 0 Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0 Node 0, zone Normal, type CMA 0 0 0 0 0 0 0 0 0 1 7 Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0 Number of blocks type Unmovable Movable Reclaimable HighAtomic CMA Isolate Node 0, zone DMA 0 1520 0 0 16 0 Node 0, zone Normal 12 2530 2 0 16 0 Notes: - The only zone that is not supported is ZONE_DEVICE. - MIGRATE_CMA will be supported soon Juan Yescas (16): mm: Page Alloc Hogger module mm: Define structs for allocation requests and store allocations mm: Define the caches for the structs req_alloc and page_alloc mm: Define function to create a dir for each online node mm: Define function to create a dir for populated zone mm: Define function to create a dir for each page order mm: Define function to create a dir for each migrate type mm: Define function that creates the "nr_pages_allocs" file mm: Read the nr_pages_allocs value given by user mm: Set the selected zone in gfp_t flags mm: Sets the migrate type in gfp_t flags mm: Define the make_alloc() function mm: Create the file associated with an allocation mm: Free pages, remove files and clean cache when one alloc fails mm: Create the "free" file to release the previously allocated pages mm: Release resources when the page alloc hogger module exits mm/Kconfig.debug | 12 + mm/Makefile | 1 + mm/page_alloc_hogger.c | 610 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 623 insertions(+) create mode 100644 mm/page_alloc_hogger.c -- 2.55.0.629.g250fe7f194-goog
Hi Juan, While I think there's possibly value in people not re-implemented their own allocation injector, I don't think there's value in having this be part of core-mm. I really don't want this to form part of any contract or to be blessed in any way by core mm as it exposes internal implementation details and I really want to avoid adding extra maintainer workload here. I'd suggest keeping it as an out-of-tree module as David proposed previously ([0]). Alternatively, keeping it as part of tooling (e.g. in tools/testing) could also work. (This is no comment on how useful it might be for debugging or testing scenarios :) -- Cheers, Lorenzo [0]:https://lore.kernel.org/all/97605949-82c5-49e0-84b6-b42e8078b55d@kernel.org/
On Thu, Aug 6, 2026 at 2:48 AM Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote: > > Hi Juan, > > While I think there's possibly value in people not re-implemented their own > allocation injector, I don't think there's value in having this be part of > core-mm. > Thanks Lorenzo for your comments. Apologies for the delay. > I really don't want this to form part of any contract or to be blessed in > any way by core mm as it exposes internal implementation details and I > really want to avoid adding extra maintainer workload here. > I understand and completely respect your concern regarding maintainer overhead and internal boundaries. Do you see a way to provide similar functionality without exposing the internal implementation? > I'd suggest keeping it as an out-of-tree module as David proposed > previously ([0]). > > Alternatively, keeping it as part of tooling (e.g. in tools/testing) could > also work. That would also work. > (This is no comment on how useful it might be for debugging or testing > scenarios :) > Thanks again for your feedback Juan > -- > Cheers, Lorenzo > > [0]:https://lore.kernel.org/all/97605949-82c5-49e0-84b6-b42e8078b55d@kernel.org/
On Tue, Aug 11, 2026 at 11:20:54AM -0700, Juan Yescas wrote: > On Thu, Aug 6, 2026 at 2:48 AM Lorenzo Stoakes (ARM) <ljs@kernel.org> wrote: > > > > Hi Juan, > > > > While I think there's possibly value in people not re-implemented their own > > allocation injector, I don't think there's value in having this be part of > > core-mm. > > > > Thanks Lorenzo for your comments. Apologies for the delay. > > > I really don't want this to form part of any contract or to be blessed in > > any way by core mm as it exposes internal implementation details and I > > really want to avoid adding extra maintainer workload here. > > > > I understand and completely respect your concern regarding maintainer > overhead and internal boundaries. > > Do you see a way to provide similar functionality without exposing the > internal implementation? > > > > I'd suggest keeping it as an out-of-tree module as David proposed > > previously ([0]). > > > > Alternatively, keeping it as part of tooling (e.g. in tools/testing) could > > also work. > > That would also work. Yeah David and I are agreed this would be the best place for it - it gives you everything you need and upstream while keeping the separation we want _and_ it allows us to write better, more thorough tests (and I see in your reply to Andrew you are planning on adding a bunch of tests which I love to hear :) So this would be great thanks! > > > (This is no comment on how useful it might be for debugging or testing > > scenarios :) > > > > Thanks again for your feedback > Juan > > > -- > > Cheers, Lorenzo > > > > [0]:https://lore.kernel.org/all/97605949-82c5-49e0-84b6-b42e8078b55d@kernel.org/ -- Cheers, Lorenzo
On 8/6/26 11:48, Lorenzo Stoakes (ARM) wrote: > Hi Juan, > > While I think there's possibly value in people not re-implemented their own > allocation injector, I don't think there's value in having this be part of > core-mm. > > I really don't want this to form part of any contract or to be blessed in > any way by core mm as it exposes internal implementation details and I > really want to avoid adding extra maintainer workload here. > > I'd suggest keeping it as an out-of-tree module as David proposed > previously ([0]). > > Alternatively, keeping it as part of tooling (e.g. in tools/testing) could > also work. Yes, I would prefer if all MM-related testing modules actually go somewhere in tools/testing. I commented on that recently when finding some of them in lib (and we also have another GUP one at least in mm). Stuff that doesn't ultimately need to be there should just be somewhere else. -- Cheers, David
On Thu, Aug 6, 2026 at 4:17 AM David Hildenbrand (Arm) <david@kernel.org> wrote: > > On 8/6/26 11:48, Lorenzo Stoakes (ARM) wrote: > > Hi Juan, > > > > While I think there's possibly value in people not re-implemented their own > > allocation injector, I don't think there's value in having this be part of > > core-mm. > > > > I really don't want this to form part of any contract or to be blessed in > > any way by core mm as it exposes internal implementation details and I > > really want to avoid adding extra maintainer workload here. > > > > I'd suggest keeping it as an out-of-tree module as David proposed > > previously ([0]). > > > > Alternatively, keeping it as part of tooling (e.g. in tools/testing) could > > also work. > Yes, I would prefer if all MM-related testing modules actually go somewhere in > tools/testing. > Thanks David, apologies for the delay. > > I commented on that recently when finding some of them in lib (and we also have > another GUP one at least in mm). Stuff that doesn't ultimately need to be there > should just be somewhere else. > I think that works too, if this module is useful for kernel developers, we could place it in tools/testing. Thanks Juan > -- > Cheers, > > David
On Wed, 5 Aug 2026 18:09:01 -0700 Juan Yescas <jyescas@google.com> wrote:
> This patch series introduces the Page Alloc Hogger. The Page Alloc Hogger
> allows you to allocate memory pages from specific nodes, zones, migration
> types, and orders directly via debugfs. This provides key benefits for
> testing and debugging:
OK, so this is targeted at kernel developers. And they may indeed find
it useful. I see value in us developing a common way for developers to
apply well-targeted stress to MM.
Probably everyone has their own favorite memory stresstest suite. Most
of these will be in userspace[*] but I see there is merit in doing it
in-kernel. Any perspective you can add to this choice would be
interesting?
Some usage scenarioizing would help. Is this being used within google?
If so, for what purpose and with what results? Sell it to us - help
your audience understand what benefit it offers to them.
If this proposal has legs then we should Document/ it separately - that
big block comment in page_alloc_hogger.c will become unweildy.
One could consider plumbing this into selftests/ in some fashion, but I
wouldn't encourage that - longrunning torture tests aren't appropriate
for selftests, which are nice and snappy. Perhaps a new
tools/testing/stresstests will one day appear.
> +obj-$(CONFIG_PAGEALLOC_HOGGER) += page_alloc_hogger.o
page_alloc or pagealloc. Choose only one, lest you drive people crazy
for ever.
Sashiko went totally nuts. Have fun with that ;) But I wouldn't do a
ton of work on this until you've heard positive noises from the MM team,
Guys, poke. wdyt, is there potential here?
https://sashiko.dev/#/patchset/20260806011048.517229-1-jyescas@google.com
[*] Back in the days when I was trying to get redhat ext3 and 2.5.x
MM to do something other than lock up or crash, I wrote a userspace
thing called "usemem". In recent times I've seen people quoting
usemem results and wondered "is that my thing". So I looked it up.
It is! And it's now quite unrecognizable.
Because, obviously, people found it useful and so they used it
and added to it and added to it and more.
And I expect the same will occur with "Page Alloc Hogger"
(terrible name, btw. How about "pagehog"? "memhog"), if it is
adopted. People will use it and will add to it.
On Wed, Aug 5, 2026 at 10:22 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Wed, 5 Aug 2026 18:09:01 -0700 Juan Yescas <jyescas@google.com> wrote:
>
> > This patch series introduces the Page Alloc Hogger. The Page Alloc Hogger
> > allows you to allocate memory pages from specific nodes, zones, migration
> > types, and orders directly via debugfs. This provides key benefits for
> > testing and debugging:
>
> OK, so this is targeted at kernel developers. And they may indeed find
> it useful. I see value in us developing a common way for developers to
> apply well-targeted stress to MM.
>
>
> Probably everyone has their own favorite memory stresstest suite. Most
> of these will be in userspace[*] but I see there is merit in doing it
> in-kernel. Any perspective you can add to this choice would be
> interesting?
>
Thanks for your comments and apologies for the delay in getting back
to you, I was gathering some examples.
I think some scenarios and tests are hard to reproduce using userspace
memory stresstests. For example memory fragmentation in one node or
fragmentation
in one zone, or fragmentation by migrate type. Testing memory fallbacks, etc.
This proposal makes these scenarios easy to reproduce.
>
> Some usage scenarioizing would help. Is this being used within google?
We are planning to add kselftests that create memory pressure in the system
and test that kswapd, oom, lmkd, compaction, etc., are called accordingly.
This tool will also be used to run benchmarks comparing 4KB vs 16kb
pagesizes under
various conditions (low memory, high memory fragmentation). Currently, in order
to create memory pressure, we modify the dts or set the mem kernel parameter to
reduce the available RAM and then cycle through apps for hours to get the
memory fragmented. With this tool, we can create memory pressure and memory
fragmentation pretty straightforward and then run the benchmarks under these
conditions.
> If so, for what purpose and with what results? Sell it to us - help
> your audience understand what benefit it offers to them.
>
That is a good point. Although this tool was written for devices using
less than 32 GBs
of memory, it could be used for servers. For example, if you want to
create memory
pressure in the different Nodes or zones in the server, you can easily
do it by running
# Alloc 500 GiB node 0 zone DMA
echo 128000 > /sys/kernel/debug/mm/node-0/zone-DMA/order-10/migrate-Reclaimable/nr_pages_allocs
# Alloc 1000 GiB node 1 zone Normal
echo 256000 > /sys/kernel/debug/mm/node-1/zone-Normal/order-10/migrate-Reclaimable/nr_pages_allocs
# Alloc 500 GiB node 2 zone Normal
echo 128000 > /sys/kernel/debug/mm/node-1/zone-Normal/order-10/migrate-Reclaimable/nr_pages_allocs
or you can run this script to allocate 500GiB across all nodes in the system:
for node in `set 0 16`; do echo 128000 >
/sys/kernel/debug/mm/node-$node/zone-Normal/order-10/migrate-Reclaimable/nr_pages_allocs;
done
When my team want to reproduce memory issues due to fragmentation, it is not
straightforward to set the memory into this state consistently with
our current tools.
Let's say that we are debugging an issue where we have enough memory
but the high
high-order allocations are failing due to memory fragmentation which
was caused by
pinned pages in the different page blocks of the zone. How could we
reproduce this fragmentation
artificially in Node 0/Zone Normal?
# cat /proc/pagetypeinfo
Page block order: 9
Pages per block: 512
Free pages count per migrate type at order 0 1 2 3 4 5
6 7 8 9 10
Node 0, zone DMA, type Unmovable 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone DMA, type Movable 1 1 1 0 1 1
2 2 1 3 708
Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone DMA, type CMA 0 0 0 0 0 0
0 0 0 1 31
Node 0, zone DMA, type Isolate 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone Normal, type Unmovable 492 445 301 31 6 3
1 0 1 1 0
Node 0, zone Normal, type Movable 387 366 357 345 341 341
329 303 291 278 559
Node 0, zone Normal, type Reclaimable 861 825 1516 1387 1176 832
473 371 361 226 10
Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone Normal, type CMA 0 0 0 0 0 0
0 0 0 1 7
Node 0, zone Normal, type Isolate 0 0 0 0 0 0
0 0 0 0 0
Number of blocks type Unmovable Movable Reclaimable
HighAtomic CMA Isolate
Node 0, zone DMA 0 1472 0 0
64 0
Node 0, zone Normal 20 1796 728 0
16 0
We could write a custom program that mmap/mlock enough memory, and then release
all pages except one in each page block. What if we want to fragment
also the zone DMA?
Using the driver proposed here, we could fragment the memory with this script:
# Allocate memory from Node 0/Zone Normal/Order 0/Migrate Reclaimable
echo 307200 > /sys/kernel/debug/mm/node-0/zone-Normal/order-0/migrate-Reclaimable/nr_pages_allocs
for i in `seq 1 307200`; do \
v=$(expr $i % 1024 != 0); \
# Release everything but one page from each page block
if [ $v = 1 ]; then echo $i > /sys/kernel/debug/mm/free; echo
"Releasing $i"; fi; \
done
# Allocate memory from Node 0/Zone Normal/Order 0/Migrate Movable
echo 307200 > /sys/kernel/debug/mm/node-0/zone-Normal/order-0/migrate-Movable/nr_pages_allocs
for i in `seq 307201 614400`; do \
v=$(expr $i % 1024 != 0); \
if [ $v = 1 ]; then echo $i > /sys/kernel/debug/mm/free; echo
"Releasing $i"; fi; \
done
After running the shell script, we have fragmented the memory;
# cat /proc/pagetypeinfo
Page block order: 9
Pages per block: 512
Free pages count per migrate type at order 0 1 2 3 4 5
6 7 8 9 10
Node 0, zone DMA, type Unmovable 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone DMA, type Movable 1 1 1 0 1 1
2 2 1 3 708
Node 0, zone DMA, type Reclaimable 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone DMA, type CMA 0 0 0 0 0 0
0 0 0 1 31
Node 0, zone DMA, type Isolate 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone Normal, type Unmovable 492 445 301 31 6 3
1 0 1 1 0
Node 0, zone Normal, type Movable 387 366 357 345 341 341
329 303 291 278 559
Node 0, zone Normal, type Reclaimable 861 825 1516 1387 1176 832
473 371 361 226 10
Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone Normal, type CMA 0 0 0 0 0 0
0 0 0 1 7
Node 0, zone Normal, type Isolate 0 0 0 0 0 0
0 0 0 0 0
Number of blocks type Unmovable Movable Reclaimable
HighAtomic CMA Isolate
Node 0, zone DMA 0 1472 0 0
64 0
Node 0, zone Normal 20 1796 728 0
16 0
If we want to do the same with Node 0/Zone DMA, we only execute:
echo 307200 > /sys/kernel/debug/mm/node-0/zone-DMA/order-0/migrate-Reclaimable/nr_pages_allocs
for i in `seq 614401 921600`; do \
v=$(expr $i % 1024 != 0); \
if [ $v = 1 ]; then echo $i > /sys/kernel/debug/mm/free; echo
"Releasing $i"; fi; \
done
# cat /proc/pagetypeinfo
Page block order: 9
Pages per block: 512
Free pages count per migrate type at order 0 1 2 3 4 5
6 7 8 9 10
Node 0, zone DMA, type Unmovable 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone DMA, type Movable 1 1 1 0 1 1
2 2 1 3 406
Node 0, zone DMA, type Reclaimable 293 293 292 292 292 293
293 293 293 292 2
Node 0, zone DMA, type HighAtomic 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone DMA, type CMA 0 0 0 0 0 0
0 0 0 1 31
Node 0, zone DMA, type Isolate 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone Normal, type Unmovable 566 377 261 33 7 3
1 0 1 1 1
Node 0, zone Normal, type Movable 290 352 344 336 330 329
321 301 296 279 559
Node 0, zone Normal, type Reclaimable 1109 1024 1928 1641 1168 521
498 374 361 226 9
Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0
0 0 0 0 0
Node 0, zone Normal, type CMA 0 0 0 0 0 0
0 0 0 1 7
Node 0, zone Normal, type Isolate 0 0 0 0 0 0
0 0 0 0 0
Number of blocks type Unmovable Movable Reclaimable
HighAtomic CMA Isolate
Node 0, zone DMA 0 868 604 0
64 0
Node 0, zone Normal 22 1796 726 0
16 0
As we can see, it is pretty straightforward to artificially reproduce
the fragmentation using
a script.
> If this proposal has legs then we should Document/ it separately - that
> big block comment in page_alloc_hogger.c will become unweildy.
>
I agree, I am happy to move it under Document/ if the tool is useful
for other kernel developers.
>
> One could consider plumbing this into selftests/ in some fashion, but I
> wouldn't encourage that - longrunning torture tests aren't appropriate
> for selftests, which are nice and snappy. Perhaps a new
> tools/testing/stresstests will one day appear.
>
>
>
> > +obj-$(CONFIG_PAGEALLOC_HOGGER) += page_alloc_hogger.o
>
> page_alloc or pagealloc. Choose only one, lest you drive people crazy
> for ever.
>
Good point, I can do that. Thanks for pointing it out.
>
>
> Sashiko went totally nuts. Have fun with that ;) But I wouldn't do a
> ton of work on this until you've heard positive noises from the MM team,
> Guys, poke. wdyt, is there potential here?
>
> https://sashiko.dev/#/patchset/20260806011048.517229-1-jyescas@google.com
>
>
> [*] Back in the days when I was trying to get redhat ext3 and 2.5.x
> MM to do something other than lock up or crash, I wrote a userspace
> thing called "usemem". In recent times I've seen people quoting
> usemem results and wondered "is that my thing". So I looked it up.
> It is! And it's now quite unrecognizable.
>
> Because, obviously, people found it useful and so they used it
> and added to it and added to it and more.
>
> And I expect the same will occur with "Page Alloc Hogger"
> (terrible name, btw. How about "pagehog"? "memhog"), if it is
> adopted. People will use it and will add to it.
>
I agree that the name is not good. I like "pagehog".
Thanks for taking the time to review it.
Greetings
Juan
>
>
© 2016 - 2026 Red Hat, Inc.