On 2/28/24 3:32 AM, Matthew Wilcox wrote: > 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? > isolate_freepages_range -> split_map_pages -> post_alloc_hook -> set_page_refcounted > 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? for powerpc kvm hash page table usage (kvm_alloc_hpt_cma()/kvm_free_hpt_cma()) I guess we don't expect them to be individually refcounted. > > --- > > 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.
