Re: [PATCH v4 05/10] mm/cma: Allow dynamically creating CMA areas

On 8/10/26 16:14, Thierry Reding wrote:
> On Fri, Aug 07, 2026 at 06:16:06PM +0200, David Hildenbrand (Arm) wrote:
>> On 8/7/26 17:54, Thierry Reding wrote:
>>> From: Thierry Reding <[email protected]>
>>>
>>> There is no technical reason why there should be a limited number of CMA
>>> regions, so extract some code into helpers and use them to create extra
>>> functions (cma_create() and cma_free()) that allow creating and freeing,
>>> respectively, CMA regions dynamically at runtime.
>>>
>>> The static array of CMA areas cannot be replaced by dynamically created
>>> areas because for many of them, allocation must not fail and some cases
>>> may need to initialize them before the slab allocator is even available.
>>> To account for this, keep these "early" areas in a separate list and
>>> track the dynamic areas in a separate list.
>>>
>>> Signed-off-by: Thierry Reding <[email protected]>
>>> ---
>>
>> Sorry that I didn't get to reply earlier to
>>
>> 	https://lore.kernel.org/all/anS0nxAwCXGWZRl9@orome/
>>
>> But I am still not convinced why we shouldn't just have a single array that
>> grows dynamically.
>>
>> "
>> After replying to T.J. I think this static array is actually a nice
>> feature in a way. It allows us to more easily make a distinction between
>> the regular CMA regions created from reserved-memory regions that
>> represent classic carveouts, and the more versatile CMA areas that could
>> be used for any purpose.
>>
>> Telling the two types apart could obviously also be solved using some
>> kind of flag stored with the CMA area, but at this point I don't really
>> see a reason why the two lists would need to be unified.
>> "
>>
>> Really, cma_for_each_early_area() + cma_for_each_area() is just nasty.
>>
>> I'd strongly vote to unify unless there is a very good reason to do it
>> separately.
> 
> Marek had an interesting suggestion to extend CMA with fixed address or
> range allocations, in which case we would only need a single CMA area.
> If that works and is acceptable, there's not much need any longer for
> cma_create()/cma_free().

That would be even better :) I didn't fully grasp what he meant, but feel free
to send a prototype of the CMA changes over!

-- 
Cheers,

David