From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: Matthew Auld <matthew.auld@intel.com>, intel-xe@lists.freedesktop.org
Cc: Matthew Brost <matthew.brost@intel.com>
Subject: Re: [PATCH] drm/xe/bo: optimise TT population for DONTNEED BOs
Date: Thu, 23 Jul 2026 18:00:34 +0200 [thread overview]
Message-ID: <82838dbfe4d30718b59b76f1e813a72d12ebd96e.camel@linux.intel.com> (raw)
In-Reply-To: <20260723133418.1201717-2-matthew.auld@intel.com>
On Thu, 2026-07-23 at 14:34 +0100, Matthew Auld wrote:
> When a VRAM buffer object is marked as DONTNEED, like in Mesa, the
> driver skips migrating its contents to system memory and instead
> purges
> the backing store during eviction (via xe_ttm_bo_purge).
>
> However, xe_evict_flags() still returns tt_placement (XE_PL_TT) for
> VRAM
> BOs even if they were marked DONTNEED. This causes
> ttm_bo_handle_move_mem() to call always call ttm_bo_populate() to
> allocate destination system pages, only for those pages to be
> immediately freed right after when xe_bo_move() calls
> xe_ttm_bo_purge().
>
> Fix this by changing xe_evict_flags() to return sys_placement
> (XE_PL_SYSTEM) for DONTNEED BOs. This causes TTM to skip the
> population
> step while still ensuring that TTM calls xe_bo_move(), so
> xe_ttm_bo_purge() still triggers.
>
> Assisted-by: Copilot:gemini-3.1-pro-preview
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Cc: Matthew Brost <matthew.brost@intel.com>
> ---
> drivers/gpu/drm/xe/xe_bo.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
> index c266fa6bade1..1daa80079608 100644
> --- a/drivers/gpu/drm/xe/xe_bo.c
> +++ b/drivers/gpu/drm/xe/xe_bo.c
> @@ -341,6 +341,11 @@ static void xe_evict_flags(struct
> ttm_buffer_object *tbo,
> return;
> }
>
> + if (xe_bo_madv_is_dontneed(bo)) {
> + *placement = sys_placement;
> + return;
> + }
> +
It might be worth adding a comment here, since it's tempting to add a
completely empty placement, like I think amdgpu does. But IIRC then the
move callback won't even get called and hence no move_notify which
triggers the deferred rebind.
/Thomas
> /*
> * For xe, sg bos that are evicted to system just triggers a
> * rebind of the sg list upon subsequent validation to
> XE_PL_TT.
prev parent reply other threads:[~2026-07-23 16:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-23 13:34 [PATCH] drm/xe/bo: optimise TT population for DONTNEED BOs Matthew Auld
2026-07-23 13:39 ` Maarten Lankhorst
2026-07-23 13:42 ` ✓ CI.KUnit: success for " Patchwork
2026-07-23 14:17 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-23 16:00 ` Thomas Hellström [this message]
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=82838dbfe4d30718b59b76f1e813a72d12ebd96e.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
/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.