It may be helpful to look at https://kernelnewbies.org/MatthewWilcox/Memdescs I don't yet have a plan for what CMA should look like in the memdesc future. Partly I just don't know CMA very well. Some help would be appreciated ... First, I'm pretty sure that cma allocations are freed as a single unit; there's no intended support for "allocate 2000MB from CMA, free 500MB-1500MB, use the first 500MB for one thing and the last 500MB for something else". Right? Second, CMA doesn't actually grub around inside struct page itself, so it has no dependencies on what struct page contains. Is that true? Third, I don't see where CMA manipulates the page refcount today. Does it rely on somebody else setting the page refcount to 1 before giving the pages to CMA? Fourth, do users of CMA rely on pages being individually refcounted? Is there a reason you've never implemented an equivalent to __GFP_COMP before? --- My strawman proposal is that, in a memdesc world, the individual pages that are free within CMA get a type 0 subtype to make them readily identifiable in memory dumps. At allocation time, the caller will pass in a memdesc to manage the pages (and CMA will assign it to all the pages, just like the BuddyAllocator will). As a step towards that, we can change CMA soon to return pages which have a zero refcount. That should catch any users which rely on individual refcounts.
