A BO's TTM priority is only ever set once, at creation time, based on the priority band of exec queues attached to its VM at that moment (xe_vm_bo_priority()), or XE_BO_PRIORITY_HIGHEST for an extobj not tied to any single VM. This misses the common flow of VM create -> BO create -> exec queue create -> VM bind: the BO is created before any exec queue exists on the VM (so it gets XE_BO_PRIORITY_HIGH, the "no exec queues yet" default), the exec queue is added afterwards (xe_vm_add_exec_queue() only re-prioritizes BOs already bound to the VM at that time), and only then is the BO bound into the VM via VM_BIND, leaving it stuck at a stale priority that no longer reflects the VM's exec queues.
It also misses a second flow specific to extobjs: create BO with no vm_id (bo->vm == NULL) -> bind -> unbind -> rebind. The unbind can lower the BO's priority to XE_BO_PRIORITY_LOW once it has no VMA mappings left anywhere (see xe_vma_destroy()), but on rebind nothing brought it back up, leaving a still-useful, freshly rebound extobj stuck at the lowest priority, an easy target for eviction/shrinking. Add op_update_bo_priority(), called from vm_bind_ioctl_ops_fini() for each DRM_GPUVA_OP_MAP operation. For a BO private to the VM being bound (bo->vm == vm), recompute the current priority band via xe_vm_bo_priority() and, if it differs, update bo->ttm.priority and move the BO to the tail of its new priority's LRU list. For an extobj (bo->vm == NULL, potentially shared with other VMs), instead restore it directly to XE_BO_PRIORITY_HIGHEST, since it is now in active use again and extobjs aren't tied to any single VM's exec queue priority band. This runs under the VM's dma-resv lock, already held via drm_exec in vm_bind_ioctl_ops_execute() since private BOs share the VM's reservation object, and extobjs are locked as part of the same bind operation. Cc: Carlos Santa <[email protected]> Cc: Ryan Neph <[email protected]> Assisted-by: GitHub_Copilot:claude-sonnet-5 Signed-off-by: Matthew Brost <[email protected]> --- drivers/gpu/drm/xe/xe_vm.c | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index 3c5da9f52f72..d42390e7ae2f 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -3554,6 +3554,38 @@ static void op_add_ufence(struct xe_vm *vm, struct xe_vma_op *op, } } +/* + * A BO's TTM priority is set when it is created, based on the priority band + * of @vm's exec queues at that time (for a private BO), or to the highest + * level (for an extobj, bo->vm == NULL). If a BO is (re)mapped into @vm + * afterwards, its priority may be stale: a private BO's VM may have gained + * or lost exec queues since, and an extobj may have been lowered to + * XE_BO_PRIORITY_LOW by xe_vma_destroy() after losing all of its VMA + * mappings. Bring it in line with the current priority band here. + */ +static void op_update_bo_priority(struct xe_vm *vm, struct xe_vma_op *op) +{ + struct xe_bo *bo; + int priority; + + if (op->base.op != DRM_GPUVA_OP_MAP) + return; + + bo = xe_vma_bo(op->map.vma); + if (!bo) + return; + + /* Private BOs are only ever bound to the VM they were created for. */ + xe_assert(vm->xe, !bo->vm || bo->vm == vm); + + priority = bo->vm ? xe_vm_bo_priority(vm) : XE_BO_PRIORITY_HIGHEST; + if (bo->ttm.priority == priority) + return; + + xe_vm_assert_held(vm); + xe_bo_update_ttm_priority(bo, priority); +} + static void vm_bind_ioctl_ops_fini(struct xe_vm *vm, struct xe_vma_ops *vops, struct dma_fence *fence) { @@ -3566,6 +3598,8 @@ static void vm_bind_ioctl_ops_fini(struct xe_vm *vm, struct xe_vma_ops *vops, if (ufence) op_add_ufence(vm, op, ufence); + op_update_bo_priority(vm, op); + if (op->base.op == DRM_GPUVA_OP_UNMAP) xe_vma_destroy(gpuva_to_vma(op->base.unmap.va), fence); else if (op->base.op == DRM_GPUVA_OP_REMAP) -- 2.34.1
