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

[Dave Airlie <airlied@gmail.com>]

On Tue, 24 Feb 2026 at 20:32, Christian König <christian.koenig@amd.com> wrote:
>
> On 2/24/26 10:43, Maxime Ripard wrote:
> > Hi Christian,
> >
> > On Fri, Feb 20, 2026 at 10:45:08AM +0100, Christian König wrote:
> >> On 2/20/26 02:14, T.J. Mercier wrote:
> >>> On Wed, Feb 18, 2026 at 9:15 AM Eric Chanudet <echanude@redhat.com> wrote:
> >>>
> >>> Hi Eric,
> >>>
> >>>> 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?
> >>
> >> Yeah we have this problem pretty much everywhere.
> >>
> >> There are both use cases where you want to account device allocations
> >> to memcg and when you don't want that.
> >>
> >> From what I know at the moment it would be best if the administrator
> >> could say for each dmem if it should account additionally to memcg or
> >> not.
> >>
> >> Using module parameters to enable/disable it globally is just a
> >> workaround as far as I can see.
> >
> > That's a pretty good idea! It would indeed be a solution that could
> > satisfy everyone (I assume?).
>
> I think so yeah.
>
> From what I have seen we have three different use cases:
>
> 1. local device memory (VRAM), GTT/CMA and memcg are completely separate domains and you want to have completely separate values as limit for them.
>
> 2. local device memory (VRAM) is separate. GTT/CMA are accounted to memcg, you can still have separate values as limit so that nobody over allocates CMA (for example).
>
> 3. All three are accounted to memcg because system memory is actually used as fallback if applications over allocate device local memory.
>
> It's debatable what should be the default, but we clearly need to handle all three use cases. Potentially even on the same system.


Give me cases where 1 or 3 actually make sense in the real world.

I can maybe take 1 if CMA is just old school CMA carved out preboot so
it's not in the main memory pool, but in that case it's just equiv to
device memory really

If something is in the main memory pool, it should be accounted for
using memcg. You cannot remove memory from the main memory pool
without accounting for it. Now we can add gpu limits to memcg, that
was going to me a next step in my series.

Whether we have that as a percentage or a hard limit, we would just
say GPU can consume 95% of the configured max for this cgroup.

3 to me just sounds like we haven't figured out fallback or
suspend/resume accounting yet, which is true, but I'm not sure there
is a reason for 3 to exist outside of the we don't know how to account
for temporary storage of swapped out VRAM objects.

Like it might be we need to have it so we have a limited transfer pool
of system memory for VRAM objects to "live in" but we move them to
swap as soon as possible once we get to the limit on that. Now what we
do on systems where no swap is available, that gets into I've no idea
space.

Static partitioning memcg up into a dmem and memcg isn't going to
solve this, we should solve it inside memcg.

Dave.