On Tue, Feb 24, 2026 at 1:42 AM Maxime Ripard mripard@redhat.com 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 echanude@redhat.com 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.