On Tue, Aug 25, 2026 at 09:19:21PM +0200, Michal Hocko wrote: > On Tue 25-08-26 14:33:48, Eric Chanudet wrote: > > 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. > > So each CMA area will have its own counter and limits?
Yes, in order to enforce a limit per CMA area this series add a page counter for each area. Areas are fixed and discovered early so the counters are added to struct mem_cgroup and initialized when the cgroup is created. An admin would then use the cgroupfs entries to assign an area limit to a given cgroup, something like the following, using the reserved area for example: mount -o remount,memory_cma_accounting /sys/fs/cgroup echo +memory > /sys/fs/cgroup/cgroup.subtree_control mkdir /sys/fs/cgroup/mycg echo 16M > /sys/fs/cgroup/mycg/memory.cma.reserved.max echo 64M > /sys/fs/cgroup/mycg/memory.max > > 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. > > No memory reclaim is triggered? Oh I see, try_charge_memcg() may try to reclaim and would do so before the area counter is checked. So a dmabuf heap allocation in CMA could end up with a page cache eviction if the memcg limit is reached by the allocation. That is down to the configuration setup by the admin, I didn't put any check that would prevent say echo 1M > ..mycg/memory.max echo 16M > ..mycg/memory.cma.reserved.max , which would exacerbate that scenario. > > 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. > > I do not follow I mangled my sentence halfway, I'm sorry. I meant that the charges persist until the resources are released. Enabling memory_cma_accounting only controls if new charges are issued. > > 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. > > I really do not understand what you mean here. Non-CMA allocations can end up in CMA physical regions when necessary (ALLOC_CMA flag). Since both CMA allocations and other system allocations are represented the same way, with differences only in properties, and they can live in the same regions, it sounds reasonable to account for both under the same counter. > > > > 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), > > hugetlb pages have their own controller > > > 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. > > yes, we can have unreclaimable memory charged to memcg, that is not a > real problem. We have all sorts of memory consumers that need to be > capped charged to the memcg. If dmabufs are another ones then fine, just > charge allocated pages from the cma area. It is the "make all cma users > memcg aware and have per cma limits" that I am really struggling with. CMA is system memory independently from its usage though, and in cases with shared CMA areas multiple users can allocate from them. Yet the kernel cannot enforce usage limits. > You cannot really assume usecase, requirements, lifetime etc. for an > arbitrary cma area. I do not think this is a viable way forward. Focus > on your real usecase, which seems to be dmabufs. While dmabufs are indeed my main use case, they are quite generic and may not always have system memory backing them (device memory). Working at the CMA allocator alleviated these disparities. > Explain what do you want to achieve and then we can think whether memcg > is the right model for that usecase Hopefully I expressed this in a better way by now. In short, enforce usage limits for concurrent CMA users using shared CMA resources. > -- > Michal Hocko > SUSE Labs > -- Eric Chanudet
