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

[Juan Yescas <jyescas@google.com>]

On Mon, Mar 23, 2026 at 2:14 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 3/19/26 01:56, Juan Yescas wrote:
> > Thanks David for you comments,
> >
> >
> > On Mon, Mar 16, 2026 at 8:52 AM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 2/27/26 03:42, Juan Yescas wrote:
> >>> Hi LSF MM organizers
> >>
> >> Hi,
> >>
> >> I'm late ...
> >>
> >>>
> >>> I would like to propose a discussion on improving our ability to
> >>> reproduce complex memory allocation and reclaim scenarios, and solicit
> >>> feedback on a debugfs-based testing interface to help trigger these
> >>> edge cases.
> >>>
> >>> == The Problem ==
> >>>
> >>> We frequently encounter complex memory management issues in the wild, including:
> >>>
> >>> - CMA allocation failures due to pinned MIGRATE_MOVABLE pages.
> >>> - Page migration and compaction failing during reclaim.
> >>> - Excessive reclaim loops triggered by specific workloads.
> >>> - OOM kills.
> >>>
> >>> Reproducing these specific memory states for debugging is currently
> >>> cumbersome. For instance, consuming most of the available
> >>> MIGRATE_MOVABLE memory, or forcing MIGRATE_UNMOVABLE allocations
> >>> specifically from Node 1 and Zone DMA directly from userspace,
> >>> requires writing custom kernel modules or relying on unreliable
> >>> userspace memory pressure tactics.
> >>
> >> I'm wondering whether an OOT module for this purpose would be sufficient?
> >>
> >> IOW, do we really have to have this in the upstream kernel, or could we
> >> have a public OOT module to perform these allocations?
> >>
> >> Then, there are no worries about API/Extensibility etc.
> >>
> > You’re right that going OOT would bypass the strict API stability and
> > extensibility requirements that come with being in-tree.
> >
> > However, there are some symbols that we would need to be exported in
> > order for the module to compile.
>
> Reason I am asking is because we had similar discussions around memory
> hot(un)plug in the past, where we decided that an OOT kernel module to
> simulate add/remove was a better choice than exposing weird APIs to user
> space.
>

Hi David, I apologize for the late reply. It’s been a bit of a
whirlwind over here with some internal issues.

> Which symbols would you need?

These are the required symbols:

ERROR: modpost: "cma_alloc" [page_alloc_debugfs.ko] undefined!
ERROR: modpost: "migratetype_names" [page_alloc_debugfs.ko] undefined!

 > I guess we'd want to call the buddy by
> specifying node+zone+order.
>
That's correct, for the no cma allocations we'll call "alloc_pages_node_noprof"

> Is specifying the migratetype really relevant?
>

Yes, we want to be able to allocate these types of memory:

MIGRATE_MOVABLE,
MIGRATE_RECLAIMABLE,
MIGRATE_CMA,

When the request is for MIGRATE_CMA, the "default_cma_region" will be
used for that allocation.

> >
> >> Or would you want to fire up this debugging on a production kernel? I
> >> would assume now.
> >>
> >
> > Yes, that is actually one of our goals. We often encounter
> > "heisenbugs" that only manifest
> > under specific workloads and we want the ability to stress the memory subystem.
> >
> > For example, if we want to increase the unmovable allocations by 16 MiB,
> > a 4 KiB kernel, we can do
> >
> > $ for i in {1..4} \
> > do  \
> >   echo 1 > /sys/kernel/debug/mm/node-1/zone-Normal/order-10/migrate-Unmovable/alloc
>
> How will we handle unmovable allocations ending up on movable memory
> (e.g., ZONE_MOVABLE)? (e.g., allocating from ZONE_MOVABLE)
>

Once the allocation is requested using

echo 1 > /sys/kernel/debug/mm/node-1/zone-Normal/order-10/migrate-Umovable/alloc

We don't care whether the allocation comes from movable/cma memory.

> Also, is there any reason why we can't do it similar to hugetlb and use
> a simple "nr_pages" variable, that can be set and read.
>

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

However, when we have a directory tree, it is harder to make mistakes
regarding the node, zone, migration type, or order.
The tree would look like this:

# tree /sys/kernel/debug/mm/
/sys/kernel/debug/mm/
`-- node-0
    |-- zone-DMA
    |   |-- order-0
    |   |   |-- migrate-CMA
    |   |   |   `-- alloc
    |   |   |   `-- release
    |   |   |-- migrate-HighAtomic
    |   |   |   `-- alloc
    |   |   |   `-- release
    ....
    |   |   |   `-- alloc
    |   |   |   `-- release
    |   |   |-- migrate-Unmovable
    |   |   |   `-- alloc
    |   |   |   `-- release
   .....
        |-- order-8
        |   |-- migrate-CMA
        |   |   `-- alloc
        |   |   `-- release
        |   |-- migrate-HighAtomic
        |   |   `-- alloc
        |   |   `-- release
    ...
        |   |   `-- alloc
        |   |   `-- release
        |   |-- migrate-Unmovable
        |   |   `-- alloc
        |   |   `-- release
        `-- order-9
            |-- migrate-CMA
            |   `-- alloc
            |   `-- release
.....
            |-- migrate-Movable
            |   `-- alloc
            |   `-- release
            |-- migrate-Reclaimable
            |   `-- alloc
            |   `-- release
            |-- migrate-Unmovable
            |    `-- alloc
            |   `-- release

> Why did you decide to use the "handle" approach?

I think it is more convenient for the user and less error prone. Many
userspace developers exist.
that want to create memory pressure by allocating CMA/Movable memory,
but they are not familiar with
the nodes, zones or orders. This debug fs interface will make the
things a bit easier for them.
>
>
>
> >  \
> > done
> >
> > And this is way more convenient than writing a test driver to make
> > only unmovable allocations.
> > The same apply for the other migrate types.
>
> Right, but the interface you provide looks like it would allow
> allocating from movable areas etc, and I am not sure that is generally
> helpful (or adds more complexity to handle).
>

This will be a self-contained driver that does not require changes in
the memory subsystem.

Thanks
Juan

> --
> Cheers,
>
> David