Re: [RFC PATCH 00/16] Page Alloc Hogger

From: Juan Yescas

Date: Fri Jul 31 2026 - 11:54:24 EST


On Thu, Jul 30, 2026 at 12:51 AM Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx> wrote:
>
> On Tue, Jul 28, 2026 at 05:36:03PM -0700, Juan Yescas wrote:
> > On Tue, Jul 28, 2026 at 12:29 PM David Hildenbrand (Arm)
> > <david@xxxxxxxxxx> wrote:
> > >
> > > On 7/23/26 09:47, Juan Yescas 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:
> > >
> > > Would it be feasible to carry this as an OOT debugging module? Would a lot of
> > > symbols be missing to achieve that?
> > >
> >
> > Thanks David for the comment.
> >
> > The only symbol that would be needed to have this module as OOT is
> > "migratetype_names".
>
> I mean you could hardcode these and be pretty safe :) I don't we're going
> to add any time soon and if we did you'd probably need to change the module
> code anyway?

Thanks Lorenzo, I agree, the names can be hardcoded.

> I feel this debug module should be a noop in core.

What would be the main concern here?

The reason I wrote this module is because my team and system teams who
work in memory,
have programs to alloc/free memory to debug memory issues. These
programs are not shared and
depending on the memory issue, developers customize their programs. If we want
to allocate memory that is not MOVABLE, we need to write custom kernel
drivers for that. This code
is reinvented constantly by developers.

With this self contained module, we can allocate any valid memory from
any node/zone/order/migrate type
without needing custom programs or drivers.

Greetings
Juan

> Cheers, Lorenzo