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

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

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

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

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

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?

-- 
Cheers,

David