On Tue, Aug 25, 2026 at 04:59:52PM +0200, Michal Hocko wrote: > On Tue 25-08-26 10:47:53, Eric Chanudet wrote: > > On Mon, Aug 24, 2026 at 10:58:18AM +0200, Michal Hocko wrote: > > > On Fri 21-08-26 14:56:52, Eric Chanudet wrote: > > > > CMA allocations are currently unaccounted for by cgroup memory > > > > controllers. As system resources, they should fall under memcg, but CMA > > > > areas partition the available space for different purposes and memcg > > > > doesn't have a good representation for that. > > > > > > Which CMA usecases are covered by this work? It would be also great to > > > spend more time describing usecases. > > > > We would like to offer some usage guaranties to userspace processes > > ending up doing allocations in CMA. > > > > For example, a shared CMA area is described in device-tree for an ARM64 > > platforms. Userspace components could then, for example, allocate from > > it through the dmabuf heap, or a device or framework-specific ioctl for > > that matter, to use the buffer with sensors. The dtb may have other CMA > > areas described additionally that may or may not be used by that > > component. In this context, we would like the ability to limit one of > > the userspace component to over-allocate and choke the other(s). > > How exactly is this supposed to work? How is the CMA access controled > and opted in for accounting. What happens when memcg limits are hit. And > many more details, please. >
The administrator opts in by mounting cgroupfs with memory_cma_accounting. At which point the cma allocator will charge CMA allocations against memcg and manages a per area counter depending on what area the allocation was made into. Assuming memory_cma_accounting is set, if a non-root cgroup makes a CMA allocation over either memcg's max limit or the per-area limit set by the admin, the allocation fails with ENOMEM. If memory_cma_accounting is dynamically unset, no the CMA allocator no longer issues charges. Whatever was already charged can be uncharged when it gets released. It looked consistent to use memcg since movable pages from regular allocations may end up in available CMA regions until a CMA allocation needs the space and has them moved. So in an extreme case, hogging the CMA space of a large enough area could trigger system memory pressure. > > memcg > > looked like a good fit to achieve this, albeit handling the areas, so a > > cgroup has a quota in a given CMA resource. > > Please expand more on why do you think this fits into the memcg model. > AFAIU we are talking about a unreclaimable memory and reservations of > CMA areas. Since memcg already accounts for some unreclaimable memory (kmem, hugetlb), or induces failure if no reclamation is possible, I did not see CMA allocations being unreclaimable to be a blocker to track what is otherwise system memory. I viewed pages allocated in CMA as guarantying special properties while being otherwise similar to pages already accounted in memcg to the point that charging them against memcg made more sense than having an entirely different pool. I can see how that could be the other way around though, especially with the per area counters, like how hugetlb have their own controller. > > This trails from an earlier post where we tried doing this using > > dmem[1], but I was unable to reconcile the requirement for memcg > > accounting[2] since from dmem I didn't have memory objects to charge nor > > the guaranty there was one. Given CMA is always system memory, it looked > > like a better fit to try something without dmem. > > > > Best, > > > > [1] > > https://lore.kernel.org/all/20260519-cgroup-dmem-memcg-double-charge-v2-0-db4d14070...@redhat.com/ > > [2] https://lore.kernel.org/all/[email protected]/ > > > > > -- > > > Michal Hocko > > > SUSE Labs > > > > > > > -- > > Eric Chanudet > > -- > Michal Hocko > SUSE Labs > -- Eric Chanudet
