On Tue, Feb 24, 2026 at 1:42 AM Maxime Ripard <[email protected]> wrote: > > Hi TJ, > > On Thu, Feb 19, 2026 at 05:14:42PM -0800, T.J. Mercier wrote: > > On Wed, Feb 18, 2026 at 9:15 AM Eric Chanudet <[email protected]> wrote: > > > An earlier series[1] from Maxime introduced dmem to the cma allocator in > > > an attempt to use it generally for dma-buf. Restart from there and apply > > > the charge in the narrower context of the CMA dma-buf heap instead. > > > > > > In line with introducing cgroup to the system heap[2], this behavior is > > > enabled based on dma_heap.mem_accounting, disabled by default. > > > > > > dmem is chosen for CMA heaps as it allows limits to be set for each > > > region backing each heap. The charge is only put in the dma-buf heap for > > > now as it guaranties it can be accounted against a userspace process > > > that requested the allocation. > > > > But CMA memory is system memory, and regular (non-CMA) movable > > allocations can occur out of these CMA areas. So this splits system > > memory accounting between memcg (from [2]) and dmem. If I want to put > > a limit on system memory use I have to adjust multiple limits (memcg + > > dmems) and know how to divide the total between them all. > > > > How do you envision using this combination of different controllers? > > I feel like it can be argued either way, and I don't really see a way > out of supporting both. > > Like you pointed out, CMA can indeed be seen as system memory, but it's > also a limited pool that you might want to place arbitrary limits on > since, unlike system memory, it can't be reclaimed, will not trigger the > OOM killer, and more generally is a much more sparse resource.
Ok thanks. Yeah I guess we'll just have to add the accounting complexity as needed to satisfy everyone's different needs.
