From: Matthew Brost <matthew.brost@intel.com>
To: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: [PATCH v2 0/4] drm/xe: Prioritize BO eviction based on VM exec queue priority
Date: Tue, 14 Jul 2026 21:28:28 -0700 [thread overview]
Message-ID: <20260715042832.3625096-1-matthew.brost@intel.com> (raw)
This series ties a BO's TTM LRU priority (i.e. how likely it is to be
picked for eviction/shrinking under memory pressure) to how userspace
is actually using the VM and BOs it belongs to, instead of treating
every BO the same.
The reasoning behind the heuristic:
- Kernel BOs, and any BO not private to a single VM (no vm_id, e.g.
shared/exported buffers), are given the highest priority so they
are the least likely to be evicted -- these are foundational or
shared resources.
- BOs private to a VM are then prioritized based on the highest
priority band userspace has assigned to any exec queue attached to
that VM: a VM with a HIGH priority exec queue keeps its BOs at the
highest priority (matching kernel/shared BOs), a VM with only
NORMAL priority queues (or none yet) gets the next priority band
down, and a VM with only LOW priority queues gets the band below
that.
- The lowest priority band is reserved exclusively for BOs (private
or shared) that have no VMA mappings left anywhere. This lets
userspace use an unbind as a signal of "drop this from my working
set, but keep the backing store around in case I need it again" --
the BO is retained, just made a preferred candidate for
eviction/shrinking until it is rebound.
Patch 1 adds the accounting: a per-priority-band count of exec queues
attached to each user VM. Patch 2 introduces the actual heuristic and
uses it both to set a BO's initial priority at creation time and to
bulk re-prioritize a VM's existing private BOs when an exec queue is
added or removed. Patch 3 fixes up staleness that these earlier
mechanisms miss: BOs created before any exec queue exists, or bound
late via VM_BIND, and BOs not tied to a single VM that get demoted to
the lowest priority and then rebound. Patch 4 introduces the
lowest-priority demotion itself, applied when a BO loses its last VMA
mapping.
Matt
Matthew Brost (4):
drm/xe: Track exec queue priority band counts for user VMs
drm/xe: Re-prioritize VM's private BOs when adding an exec queue
drm/xe: Fix up BO TTM priority for late VM binds
drm/xe: Lower BO TTM priority to lowest when fully unmapped from VM
drivers/gpu/drm/xe/xe_bo.c | 18 ++-
drivers/gpu/drm/xe/xe_bo.h | 3 +-
drivers/gpu/drm/xe/xe_bo_types.h | 3 +
drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
drivers/gpu/drm/xe/xe_vm.c | 205 +++++++++++++++++++++++++++++--
drivers/gpu/drm/xe/xe_vm.h | 1 +
drivers/gpu/drm/xe/xe_vm_types.h | 7 ++
7 files changed, 221 insertions(+), 18 deletions(-)
--
2.34.1
next reply other threads:[~2026-07-15 4:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 4:28 Matthew Brost [this message]
2026-07-15 4:28 ` [PATCH v2 1/4] drm/xe: Track exec queue priority band counts for user VMs Matthew Brost
2026-07-15 4:28 ` [PATCH v2 2/4] drm/xe: Re-prioritize VM's private BOs when adding an exec queue Matthew Brost
2026-07-15 5:02 ` sashiko-bot
2026-07-15 4:28 ` [PATCH v2 3/4] drm/xe: Fix up BO TTM priority for late VM binds Matthew Brost
2026-07-15 4:51 ` sashiko-bot
2026-07-15 4:28 ` [PATCH v2 4/4] drm/xe: Lower BO TTM priority to lowest when fully unmapped from VM Matthew Brost
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=20260715042832.3625096-1-matthew.brost@intel.com \
--to=matthew.brost@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox