On Tue, Nov 03, 2026 at 12:02:02PM +0000, Matthew Auld wrote: > On 11/07/2026 03:55, Matthew Brost wrote: > > On L2-flush-optimized HW with a dma-resv (non-fault) VM, evicting a BO > > only needs to flush the L2 cache before the migration copy runs; the > > mappings themselves are torn down and rebuilt lazily via > > drm_gpuvm_bo_evict() and a subsequent rebind. Today this flush is done > > by waiting for the BO to go idle and then issuing a synchronous TLB > > invalidation per mapping VMA from inside xe_bo_trigger_rebind(). Both > > the idle wait and the synchronous invalidation stall the calling thread > > while holding the BO dma-resv lock, serializing the move behind all > > in-flight GPU work on the BO. > > > > Replace this with an asynchronous flush. Add xe_vm_flush_vm_bo_tlb_async() > > which, for each VMA mapping the BO on each present tile, queues a TLB > > invalidation job on the tile migrate (kernel) exec queue. The jobs depend > > on the BO's in-flight GPU work, captured once as a singleton over > > DMA_RESV_USAGE_BOOKKEEP, so the flush only fires once the GPU is done with > > the current mapping. Each job's completion fence is installed into the > > BO's dma-resv as a DMA_RESV_USAGE_KERNEL fence, so the migration copy - > > which waits on the resv - waits on the flush without stalling this thread. > > > > No PTEs are zapped and vma->tile_invalidated is left untouched: the > > mapping stays valid until the lazy rebind, and the only work performed > > here is the L2 flush. On any failure the caller falls back to the > > existing blocking wait-idle plus xe_vm_invalidate_vma() path. > > > > Cc: Thomas Hellström <[email protected]> > > Cc: Tejas Upadhyay <[email protected]> > > Assisted-by: GitHub_Copilot:claude-opus-4.8 > > Signed-off-by: Matthew Brost <[email protected]> > > I think this one was split out right? But not merged yet?
Yes, we can split this one out and in fact did earlier [1]. Let me respin this one as standalone patch today. Matt [1] https://patchwork.freedesktop.org/series/170046/
