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
