All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Matthew Brost" <matthew.brost@intel.com>,
	intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v4 1/5] drm/xe: Bump the LRU of every BO an exec touches
Date: Tue, 27 Oct 2026 18:59:16 +0000	[thread overview]
Message-ID: <sashiko-outbox-187044@kernel.org> (raw)
In-Reply-To: <20261027183638.1031299-2-matthew.brost@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] drm/xe: xe_vm_bump_lru() never visits private BOs in drm_exec loop
--

commit 035844b594106f3b21b07d586a5574fd0b1e0af5
Author: Matthew Brost <matthew.brost@intel.com>

drm/xe: Bump the LRU of every BO an exec touches

This commit updates xe_vm_bump_lru() to replace the drm_gpuvm_is_extobj()
check in its drm_exec_for_each_locked_object() loop with explicit checks
skipping xe_vm_obj(vm) and BOs whose bulk_move matches vm->lru_bulk_move,
intending to bump non-bulk-moved private BOs such as those in fault-mode VMs.

> diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
> index 1ee72721b2ce3..2b84721804a77 100644
> --- a/drivers/gpu/drm/xe/xe_vm.c
> +++ b/drivers/gpu/drm/xe/xe_vm.c
> @@ -426,10 +426,8 @@ int xe_vm_validate_rebind(struct xe_vm *vm, struct drm_exec *exec,
>   * @vm: The vm for which we are bumping LRUs.
>   * @exec: The struct drm_exec with the locked GEM objects.
>   *
> - * Move the VM's private BOs, and all external objects locked by @exec,
> - * to the LRU tail. Private BOs are moved in bulk using @vm's
> - * &xe_vm.lru_bulk_move. External objects, which may be shared with other
> - * VMs, are not part of that bulk move and are bumped individually.
> + * Move all BOs locked by @exec to the LRU tail. Those covered by @vm's
> + * &xe_vm.lru_bulk_move are moved in bulk, the rest individually.
>   */
>  void xe_vm_bump_lru(struct xe_vm *vm, struct drm_exec *exec)
>  {
> @@ -439,10 +437,17 @@ void xe_vm_bump_lru(struct xe_vm *vm, struct drm_exec *exec)
>  	spin_lock(lru_lock);
>  	ttm_lru_bulk_move_tail(&vm->lru_bulk_move);
>  	drm_exec_for_each_locked_object(exec, obj) {
> -		if (!drm_gpuvm_is_extobj(&vm->gpuvm, obj))
> +		struct xe_bo *bo;
> +
> +		/* The VM's dummy resv object, not a BO. */
> +		if (obj == xe_vm_obj(vm))
> +			continue;
> +
> +		bo = gem_to_xe_bo(obj);
> +		if (bo->ttm.bulk_move == &vm->lru_bulk_move)
>  			continue;
>  
> -		ttm_bo_move_to_lru_tail(&gem_to_xe_bo(obj)->ttm);
> +		ttm_bo_move_to_lru_tail(&bo->ttm);

[Severity: Medium]
Can drm_exec_for_each_locked_object() in xe_vm_bump_lru() ever visit a
private BO of the VM?

In drivers/gpu/drm/xe/xe_bo.c:__xe_bo_create_locked(), private BOs (where
vm is non-null) are initialized with xe_vm_resv(vm) as their reservation
object:

	bo = xe_bo_init_locked(xe, bo, tile, vm ? xe_vm_resv(vm) : NULL,
			       vm && !xe_vm_in_fault_mode(vm) &&
			       flags & XE_BO_FLAG_USER ?
			       &vm->lru_bulk_move : NULL, size,
			       cpu_caching, type, flags, NULL, exec);

Because private BOs share the VM's dma_resv, drm_gpuvm_is_extobj() is false
and they are never added to gpuvm->extobj.list.

When callers prepare the drm_exec context before calling xe_vm_bump_lru()
(via xe_validation_exec_lock() -> drm_gpuvm_exec_lock() in xe_exec_ioctl()
or xe_preempt_work_begin() in preempt_rebind_work_func()),
drm_gpuvm_prepare_vm() only locks xe_vm_obj(vm) and
drm_gpuvm_prepare_objects_locked() only locks external objects from
gpuvm->extobj.list:

	drm_gpuvm_resv_assert_held(gpuvm);
	list_for_each_entry(vm_bo, &gpuvm->extobj.list, list.entry.extobj) {
		if (drm_gpuvm_bo_is_zombie(vm_bo))
			continue;

		ret = exec_prepare_obj(exec, vm_bo->obj, num_fences);

In addition, even when the follow-up commit a6d00986d9f1 ("drm/xe: Bump the
LRU on a successful page fault") calls xe_vm_bump_lru() from
xe_pagefault_handle_vma(), xe_pagefault_begin() -> xe_vm_lock_vma() only
locks xe_vm_obj(vm) and external BOs:

	err = drm_exec_lock_obj(exec, xe_vm_obj(vm));
	if (!err && bo && !bo->vm)
		err = drm_exec_lock_obj(exec, &bo->ttm.base);

Since private BOs are never recorded in exec->objects, the loop in
xe_vm_bump_lru() only ever visits xe_vm_obj(vm) and external BOs (where
bo->vm and bo->ttm.bulk_move are always null). Does this mean the
bo->ttm.bulk_move == &vm->lru_bulk_move check is unreachable and private BOs
without a bulk_move (such as fault-mode private BOs or private BOs detached
from bulk_move in xe_gem_object_close()) still never get their LRU bumped?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027183638.1031299-1-matthew.brost@intel.com?part=1

  reply	other threads:[~2026-10-27 18:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 18:36 [PATCH v4 0/5] Add a minimum age gate to the shrinker + LRU fixes Matthew Brost
2026-10-27 18:36 ` [PATCH v4 1/5] drm/xe: Bump the LRU of every BO an exec touches Matthew Brost
2026-10-27 18:59   ` sashiko-bot [this message]
2026-10-27 19:58     ` Matthew Brost
2026-10-27 18:36 ` [PATCH v4 2/5] drm/xe: Bump the LRU on a successful page fault Matthew Brost
2026-10-27 18:49   ` sashiko-bot
2026-10-27 18:36 ` [PATCH v4 3/5] drm/xe: Leave the VM bulk move on BO release, not on GEM close Matthew Brost
2026-10-27 18:47   ` sashiko-bot
2026-10-27 19:01     ` Matthew Brost
2026-10-27 19:40       ` Matthew Brost
2026-10-27 18:36 ` [PATCH v4 4/5] drm/ttm: Allow skipping to the next priority in the bo LRU cursor Matthew Brost
2026-10-27 18:36 ` [PATCH v4 5/5] drm/xe: Add a minimum age gate to the shrinker Matthew Brost
2026-10-27 19:00   ` sashiko-bot
2026-10-27 18:47 ` ✗ CI.checkpatch: warning for Add a minimum age gate to the shrinker + LRU fixes Patchwork
2026-10-27 18:49 ` ✓ CI.KUnit: success " Patchwork
2026-10-27 19:23 ` ✗ Xe.CI.BAT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-187044@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.