Re: [PATCH] drm/xe: Fix unnecessary host-side population of ttm_tt on non-TT resources

[Matthew Brost]

On Wed, Aug 26, 2026 at 07:01:21PM -0700, Matthew Brost wrote:

Dave ping. Question below.

> On Thu, Aug 20, 2026 at 10:34:49PM -0400, Nathan Bourgeois wrote:
> > > Shouldn't we just be calling xe_bo_validate() here instead of
> > > ttm_tt_populate? (With the correct xe_validation_guard() wrapping).
> > 
> > > Yes, this might be a better solution, making ttm_bo_setup_export()
> > > completely unnecessary.
> > 
> > If ttm_bo_setup_export() is unnecessary, I'm happy to change the patch
> > or make a new patch. I will attempt to implement and test this locally.
> > 
> > > This part looks good as different patch from what I'm assuming will be a
> > > TTM fix.
> > 
> > Regarding this, what do you recommend I do, assuming the patch
> > remains local to drm/xe? I'm still learning the ropes of contributing.
> > 
> 
> 
> For Xe I believe Thomas and I aligned a xe_bo_validate with a correct
> xe_validation_guard is the Xe preferred solution in the existing
> design... But a question to Dave below before I commit to anything.
> 
> > Nathan
> > 
> > On Thu, Aug 20, 2026 at 9:08 PM Dave Airlie <airlied@xxxxxxxxx> wrote:
> > >
> > > > Yes, this might be a better solution, making ttm_bo_setup_export()
> > > > completely unnecessary.
> > > >
> > > > It's also a bit odd that, in flows where we don't have backing storage
> > > > on export, we populate with pages and charge the system memory cgroup,
> > > > only to move the data to VRAM when the import attach is triggered,
> > > > resulting in a copy and a change in cgroup charging.
> > > >
> > > > I guess the question is why was ttm_bo_setup_export() introduced over
> > > > just a validation at export?
> > > >
> > >
> > > I'd like to think I had an answer for that, but I don't. Likely
> > > because I wasn't thinking about VRAM charging at all, and just
> > > worrying about making sure we had populated some pages for system
> > > memory ones, so the other side couldn't DoS us.
> > >
> 
> Dave:
> 
> We don't charge any cgroups yet, right? This would only come into play
> once a version of [1] merges, correct?
> 
> What would prevent the pages populated for a TTM BO from being
> immediately reclaimed and discarded? I'm fairly certain Xe's shrinker
> could do exactly that, since we don't pin those pages. This seems to
> imply that we'd need to store the cgroup associated with the TTM BO at
> creation time and charge allocations to that cgroup, regardless of which
> task ultimately triggers the page allocation.
> 
> Another option, instead of validating, is to revert
> ttm_bo_setup_export() entirely and rethink the overall approach as part
> of [1].
> 
> Matt
> 
> [1] https://patchwork.freedesktop.org/series/169831/
> 
> > > Dave.