Re: drm/ttm/memcg/lru: enable memcg tracking for ttm, xe and amdgpu driver (part 2) (v2).

On Thu, 23 Jul 2026 at 00:35, Thomas Hellström
<[email protected]> wrote:
>
> Hi, Dave,
>
> On Mon, 2026-07-06 at 15:22 +1000, Dave Airlie wrote:
> > This is just a repost with a number of sashiko identified problems
> > that I fixed.
> >
> > I committed the vmstat counters and list lru changes, and they are
> > now in tree.
> >
> > This is the remainder of this series. Intel have expressed interest
> > in getting
> > this landed for xe, we can drop the amdgpu changes for now if they
> > can't get
> > across the line.
> >
> > I've dropped all previous acks/reviews.
> >
> > This series adds the memcg counters for GPU active and GPU reclaim to
> > align
> > with the two global vmstats. It adds an accounting flag to TTM
> > alloc/populate,
> > and enables memcg tracking and shrinker support in TTM.
> >
> > Then it adds amdgpu and xe support.
> >
> > I think for this to land, Christian holds the main objection which I
> > still fail
> > to fully understand beyond it doesn't solve all the problems we ever
> > have had
> > with cgroups and drm, so we shouldn't even bother, and maybe we could
> > do it at
> > the object level, and integrated with dmem, and android cross process
> > accounting,
> > but I still feel this is a good baseline.
> >
> > I think this is the right layer to hook this into TTM, where we
> > allocate memory
> > and I think accounting for this memory in a proper way should be
> > done.
> >
> > Intel folks (Thomas/Maarten) please review and express concerns as
> > well.
>
> Some questions about the design that might belong in the cover-letter.
>
> - First, Since from my understanding gpu shmem allocations are charged
> against memcg, (i915 igfx and to some extent dgfx), I think this makes
> sense, although it would be good to have an outlook:
>
> 1) What about system memory allocations targeting suspend / hibernate
> evictions, will they be charged against the root cgroup?

This was a problem in my first memory tracking patchset, I didn't want
to track these allocations against the stats, but Matt Brost fixed
some problems with this idea. I think maybe charging against the root
cgroup is the proper option here.

>
> 2) Plan for limits on total gpu pages / pinned gpu pages? Is dmemcg a
> fit for such limits (coexisting with memcg) or should such limits be
> implemented in memcg?

I was just letting memcg control this, at least account first, then
work out how to limit within how things work now, I'm not sure how
dmemcg fits in here, I need to also look into the other discussions
and try and workout where dmemcg could be used.

>
> 3) IIRC I noticed a patch for dma-heaps where dmemcg was suggested for
> android, since it separates GPU memory and system memory. Do we plan
> simething similar here, based on config options?

I think that is Christian's concern, that we shouldn't do this at all
here, and we should do it with dmemcg instead, but it seemed a bit
handwavy and I'm not sure how to turn it into a concrete way forward.

Dave.