CMA, memdescs and folios

[Matthew Wilcox <willy@infradead.org>]

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.