On Wed, Aug 26, 2026 at 10:04:27AM +0200, Michal Hocko wrote: > > > 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. > > Thanks. Yes this is more clear now. And it resembles hugetlb situation > more than memcg. You simply need a memory pool specific access and usage > control. Dispersing that to a global memcg limit seems rather coarse and > I would say impractical. So it really calls for a per pool control with > an understanding of how the specific pool really works.
I'm not entirely sure what you meant there, but I think we also need to have it account in a "global" limit somewhere. Which CMA pool is backing a CMA device allocation is pretty unpredictable and unstable across boots, so if userspace wants to put meaningful limits somewhat generically, we'll need some kind of catchall limit. Maxime
signature.asc
Description: PGP signature
