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

["Thomas Hellström" <thomas.hellstrom@linux.intel.com>]

On Mon, 2026-07-06 at 17:55 +1000, Dave Airlie wrote:
> On Mon, 6 Jul 2026 at 15:23, Dave Airlie <airlied@gmail.com> 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 put the latest code at
> https://github.com/airlied/linux/tree/ttm-memcg-objcg
> 
> I've been fixing more sashiko found issues in there before I repost
> in
> a few days.
> 
> I've reordered things a little in the branch but mostly the same
> code.
> 
> Dave.

I have a couple of additional patches to this series to ensure shmem
memory allocated as part of shrinking or swapout ends up accounted to
the same cgroup that allocated the TTM memory. It looks like recursive
per-cgroup shrinking is not an issue, since somebody thought about that
already.

> 
> > 
> > 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.

The initial use-case for us is being able to pin rather substantial
amounts of system memory due to potential upcoming hardware features.
While RDMA is using RLIMIT_MEMLOCK for this, that is per process and an
attacker could easily launch a number of processes and pin all of
system memory, so the thing optionally protecting from the DoS is the
memcg limit. So regardless of whether we also account against
RLIMIT_MEMLOCK or not, we need an additional cgroups limit.

Moving forward, there also a need of limiting the amount of allocated
graphics memory only, due to the way certain apps behave when probing
for available memory. :/.

I have unfortunately missed large parts of the memcg vs dmemcg
discussion, but I asked Claude to fish out as much of the essentials as
possible from the mailing lists so I can read up.

Thanks,
Thomas


> > 
> > Regards,
> > Dave.
> >