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

[Juan Yescas <jyescas@google.com>]

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.

> 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
 \
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.

Having this driver upstream allows us to trigger these allocations
on-demand without the friction (or security risk) of
loading unsigned OOT modules into a locked-down device.

Thanks
Juan

> --
> Cheers,
>
> David