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

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

On 4/8/26 02:12, Juan Yescas wrote:
> 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:
>>> 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!

cma_alloc() will be exported soon:

https://lore.kernel.org/r/20260331-dma-buf-heaps-as-modules-v4-5-e18fda504419@kernel.org


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

I'd assume that you can work around that?

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

Well, you should.

If you end up doing something like

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?

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

I meant something like:

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

(not sure if we really want to specify the migratetype)

-- 
Cheers,

David