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

["David Hildenbrand (Arm)" <david@kernel.org>]

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.

Which symbols would you need? I guess we'd want to call the buddy by
specifying node+zone+order.

Is specifying the migratetype really relevant?

> 
>> 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)

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.

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



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

-- 
Cheers,

David