Re: [PATCH v2 0/3] dma-buf: heaps: cma: enable dmem cgroup accounting

[T.J. Mercier]

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