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

[Juan Yescas]

On Fri, Jul 31, 2026 at 8:55 AM Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx> wrote:
>
> On Fri, Jul 31, 2026 at 08:32:35AM -0700, Juan Yescas wrote:
> > 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.
>
> Yeah :) I think not such an issue.
>
> >
> > > 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.
>
> Exposing internal implementation details via debugfs is problematic as a core
> feature.
>

I see your concern.  However, the information this module makes
available is already
visible in /proc/pagetypeinfo.

> It's not impossible for this to be upstream however as a separate driver on the
> basis of people re-inventing?

You are right, I should have mentioned the most important reasons for
upstreaming this module.

We are planning to use this module to:

- test kswap/direct reclaim/OOM/etc are triggered under certain
conditions (add test cases)
- debug CMA allocations
- benchmark apps  (4kb vs 16kb page size) under the same memory pressure and
measure # reclaims/kswap triggers/OOM conditions, etc.
- there are issues reported by partners that only happened when memory
is fragmented and
memory allocations fall back to different migrate types, etc. Being
able to reproduce these memory conditions
with the current tools is hard; however, this module makes that easy.

Thanks
Juan

>
> >
> > 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
>
> --
> Cheers, Lorenzo