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:

quoted

On 8/7/26 17:54, Thierry Reding wrote:

quoted

From: Thierry Reding <redacted>

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

Sorry that I didn't get to reply earlier to

	https://lore.kernel.org/all/anS0nxAwCXGWZRl9@orome/ (local)

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