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). memcg looked like a good fit to achieve this, albeit handling the areas, so a cgroup has a quota in a given CMA resource. 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
