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

[Juan Yescas <jyescas@google.com>]

On Thu, Apr 9, 2026 at 1:06 AM David Hildenbrand (Arm) <david@kernel.org> wrote:
>
> >>
> >> echo 1 >
> >> /sys/kernel/debug/mm/node-1/zone-movable/order-10/migrate-Movable/alloc
> >>
> >> You are just breaking ZONE_MOVABLE guarantees. Or what am I missing?
> >
> > I see. How should the ZONE_MOVABLE allocations be handled? Should they
> > be excluded?
>
> Well, the same applies to MIGRATE_CMA: if you end up placing unmovable
> allocations in these areas, you will break these scenarios.
>

I see what you mean. I was not understanding your point. In that case,
the driver will have to remove the unmovable or
Invalid migrate types directories from the sysfs interface. Only valid
migrate types, orders will be allowed.

The same applies to ZONE_MOVABLE. Only valid migrate types must be
included in the sysfs directories.

> Your driver would have to support page migration, but that's not
> trivial. For example, movable_ops pages currently only support order-0
> pages.
>

I agree with you. If we only allow valid migrate types, we don't have
to support page migration :)

> >
> >>
> >>>
> >>>
> >>> We could use a "nr_pages" variable, but we would also need to set the
> >>> node, zone and migrate type.
> >>>
> >>> It would be cumbersome and error prone to have something like this:
> >>>
> >>> echo "Node1/zone-Normal/MIGRATE_RECLAIMABLE/8" > /proc/kernel/debug/mm/nr_pages
> >>
> >> I meant something like:
> >>
> >> echo 1 >
> >> /sys/kernel/debug/mm/node-1/zone-Normal/order-10/migrate-Umovable/nr_pages
> >
> > Got it, we can do something like that. It makes more sense.
> >
> >>
> >> (not sure if we really want to specify the migratetype)
> >>
> >
> > The migrate type is important because we want to make both MIGRATE_CMA
> > and MIGRATE_RECLAIMABLE allocations.
>
> See above regarding MIGRATE_CMA.
>
> But in general, bypassing the page allocator and just allocating random
> pages is not really nice, not even for a debug feature.
>

I agree. My intent is not to bypass the page allocator. We will use
the page allocator and
This will allow only valid cases (I will remove invalid migrate types
from the sysfs directories for CMA and ZONE_MOVABLE).

> In particular for the scenarios you mentioned:
>
>         - CMA allocation failures due to pinned MIGRATE_MOVABLE pages.
>
> I think some decent user-space reproducers might be a lot more elegant.
>
> I guess for CMA, you'd want a way to allocate some ordinary *user space*
> (anonymous) memory and be able to check whether the memory was allocated
> on CMA memory, to then fire up a page pinning storm and concurrently
> trying to allocate the memory.
>
> So maybe you really want a debug mechanism to migrate a (movable) user
> space page into a CMA area?
>
One intent of this driver is to debug CMA issues (pinned MOVABLE pages). This
The driver will allow easy reproduction of the case you just
mentioned. For example,
I will allocate most of the MOVABLE pages and then trigger a CMA
allocation, that might trigger a migration.

However, the driver's main goal is to put the system into low-memory conditions.
so we can reproduce OOO, kswad, lmkd issues seeing in the devices.

Thanks
Juan

> --
> Cheers,
>
> David