[RFC PATCH v2 0/1] drm/xe: avoid reclaim/restore stalls for VM-bound WC BOs

[Neil Zhong]

Hi Xe maintainers,

We are looking for feedback on an Xe reclaim policy change motivated by
repeatable HDR 4K60 playback stalls on two 8 GiB Panther Lake systems.

The stalls occur after memory pressure causes the Xe shrinker to back up
pages from WC BOs which are still mapped through VM_BIND. Restoring one
of those BOs allocates WB pages and runs set_pages_array_wc(). The x86
CPA cache/TLB flush is synchronous while validation holds the BO's
dma-resv, so unrelated EXEC, VM_BIND and dma-buf operations can wait for
hundreds of milliseconds on the same reservation object.

This RFC skips non-purge reclaim for WC BOs while at least one GPUVA
mapping remains. It does not change object lifetime. VM_UNBIND, VM
destruction and process exit remove the mappings and drop the existing
VMA references, after which the BO is reclaimable or destroyed normally.
Purgeable BOs are not skipped.

The main questions for review are:

  - Is the presence of a GPUVA mapping an acceptable residency signal,
    or should the policy also require recent GPU activity?
  - Should severe reclaim be allowed to override this policy instead of
    keeping mapped WC BOs resident unconditionally?
  - Is an A/B module parameter useful for this RFC, or should the policy
    be expressed without a user-visible knob?
  - Would retaining a bounded number of converted WC pages in the TTM
    pool be preferable for the remaining allocation-time CPA latency?

Observed pre-change ioctl maxima were 549 ms for XE_EXEC, 291 ms for
XE_VM_BIND and 343 ms for DMA-BUF IMPORT. With this patch, a 21-minute
capture had no instance of those ioctls over 16.7 ms; maxima were 348 us,
136 us and 20 us. The ttm_tt_restore maximum fell from 80.6 ms to
8.33 ms, and the WC conversion rate fell by about 82 times.

The post-change run kept about 3 GiB MemAvailable. DMA-BUF accounting
also fell from 26 objects / 664 MiB to 21 objects / 544 MiB during
playback, confirming that normal unbind and destruction still release
the working set.

Changes in v2:
  - Call ttm_bo_shrink_suitable() before the Xe-specific WC predicate,
    so ttm_bo->ttm is known to be non-NULL before checking its cache mode.

The patch is based on drm-xe-next commit 05649458e4bc ("drm/xe/bo:
optimise TT population for DONTNEED BOs").

Thanks,
Neil

Neil Zhong (1):
  drm/xe: keep VM-bound WC BOs resident during reclaim

 drivers/gpu/drm/xe/xe_defaults.h |  1 +
 drivers/gpu/drm/xe/xe_module.c   |  6 ++++++
 drivers/gpu/drm/xe/xe_module.h   |  2 +-
 drivers/gpu/drm/xe/xe_shrinker.c | 28 ++++++++++++++++++++++++++++
 4 files changed, 36 insertions(+), 1 deletion(-)


base-commit: 05649458e4bc2e45eb8d231a7a9b00dd6c9e8206
-- 
2.50.1 (Apple Git-155)