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

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

Thierry

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmp53LYACgkQ3SOs138+
s6F2pA//agw5g+ad2JaahbYD22vSCRqW3CiqP6DioCJAxsagk9tg5EhZHpBTyXgx
NeLeY+2kE3x6TL2VgqHJ4y8hoBb9s8kMQ/Y1mzKbX42KBaSncC7KOHxHC4oAYZ/Y
GIzavTlTlWZlGrD9qC/3YmmWdG7aHRr/UXALcH8VhYqn65ABqGIkmVmAcFBkZCC6
QAsB0WWbU1GVW7adArp/XjeywXwzYbuDjrhYMccXmfBexX5iA7dqyEBLybPiAhiw
/dN0PzpxaKReMS62gTC8Vl7nRW9mMC5NJpnDfMXzQtz5LBxYQkgUM07SFF4Z1cpH
ndEI0GkQyLkesWA8HJWysBbKHuO053/jjcE1+3JW61POx8TSmHPIW0Y52kE5O7h+
639yzEAlbLtPXsq9zQz6xpstENU5reyLz+IBhH3XC+f0RawuNb2YOnP29ayByUkS
o5Eg0kYjFGZP82xhBRlmveTPfBrTe/Un1wfJjnPMNttHrJaK7n3nlOrI6O7YAFau
Ou3/c15vyAOs1JrqdxCnPk4GOQFfYCwiK9cogcw/k2q6tgoSTjxuZsxqmmzOTAZx
Xj0mKBiV6RR5VCygyH+6tbdoPERl3Y8LHEP/cc642K9ldPi2Xjdqiylwt/4v7hkV
VM2qHuSnW8bwLF8N3ee2tCKpCmsx+rjwPK2tyQgPc8ts1VvqSyI=
=OEKA
-----END PGP SIGNATURE-----