All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Auld <matthew.auld@intel.com>
To: intel-xe@lists.freedesktop.org
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: [PATCH 3/3] drm/ttm, drm/xe: Drop the ttm_tt on null moves to VRAM
Date: Sat,  7 Nov 2026 17:26:52 +0000	[thread overview]
Message-ID: <20261107-oom-fun-v1-3-be9eb05b82ed@intel.com> (raw)
In-Reply-To: <20261107-oom-fun-v1-0-be9eb05b82ed@intel.com>

From: Thomas Hellström <thomas.hellstrom@linux.intel.com>

A BO created with DRM_XE_GEM_CREATE_FLAG_DEFER_BACKING starts in system
placement with an unpopulated ttm_tt. Its initial move to VRAM has no
source data and uses ttm_bo_move_null(), which unlike
ttm_bo_move_accel_cleanup() leaves bo->ttm attached. If the VRAM BO is
later exported, ttm_bo_setup_export() populates that stale ttm_tt,
pinning unused, unshrinkable host pages equal to the BO size and
potentially exhausting host RAM.

Add ttm_bo_move_null_drop_tt() to destroy the ttm_tt when moving to a
manager that doesn't use one, and use it in xe_bo_move().

Fixes: 91494dee1091 ("xe: populate buffers before exporting them.")
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 20 ++++++++++++++++++++
 drivers/gpu/drm/xe/xe_bo.c        |  6 +++---
 include/drm/ttm/ttm_bo.h          |  2 ++
 3 files changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c
index f9458a4d5a09..0ab52be3a5f7 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -756,6 +756,26 @@ void ttm_bo_move_sync_cleanup(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_move_sync_cleanup);
 
+/**
+ * ttm_bo_move_null_drop_tt - assign memory without moving data, dropping the TT
+ * @bo: The buffer object.
+ * @new_mem: The memory to be assigned.
+ *
+ * Like ttm_bo_move_null(), but if the memory manager of @new_mem doesn't use
+ * a struct ttm_tt, also destroy @bo's ttm_tt, mimicking what
+ * ttm_bo_move_accel_cleanup() does. The caller must hold the bo's
+ * reservation, and the ttm_tt must not hold data that needs to be preserved.
+ */
+void ttm_bo_move_null_drop_tt(struct ttm_buffer_object *bo,
+			      struct ttm_resource *new_mem)
+{
+	if (!ttm_manager_type(bo->bdev, new_mem->mem_type)->use_tt)
+		ttm_bo_tt_destroy(bo);
+
+	ttm_bo_move_null(bo, new_mem);
+}
+EXPORT_SYMBOL(ttm_bo_move_null_drop_tt);
+
 /**
  * ttm_bo_pipeline_gutting - purge the contents of a bo
  * @bo: The buffer object
diff --git a/drivers/gpu/drm/xe/xe_bo.c b/drivers/gpu/drm/xe/xe_bo.c
index 0181f73ef66d..6628db44951f 100644
--- a/drivers/gpu/drm/xe/xe_bo.c
+++ b/drivers/gpu/drm/xe/xe_bo.c
@@ -1178,7 +1178,7 @@ static int xe_bo_move(struct ttm_buffer_object *ttm_bo, bool evict,
 	}
 
 	if ((move_lacks_source && !needs_clear)) {
-		ttm_bo_move_null(ttm_bo, new_mem);
+		ttm_bo_move_null_drop_tt(ttm_bo, new_mem);
 		goto out;
 	}
 
@@ -1313,7 +1313,7 @@ static int xe_bo_move(struct ttm_buffer_object *ttm_bo, bool evict,
 						new_mem);
 		if (ret) {
 			dma_fence_wait(fence, false);
-			ttm_bo_move_null(ttm_bo, new_mem);
+			ttm_bo_move_null_drop_tt(ttm_bo, new_mem);
 			ret = 0;
 		}
 	} else {
@@ -1324,7 +1324,7 @@ static int xe_bo_move(struct ttm_buffer_object *ttm_bo, bool evict,
 		 */
 		dma_resv_add_fence(ttm_bo->base.resv, fence,
 				   DMA_RESV_USAGE_KERNEL);
-		ttm_bo_move_null(ttm_bo, new_mem);
+		ttm_bo_move_null_drop_tt(ttm_bo, new_mem);
 	}
 
 	/*
diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h
index 32791c4db2a9..123ef68bd849 100644
--- a/include/drm/ttm/ttm_bo.h
+++ b/include/drm/ttm/ttm_bo.h
@@ -480,6 +480,8 @@ int ttm_bo_move_accel_cleanup(struct ttm_buffer_object *bo,
 			      struct ttm_resource *new_mem);
 void ttm_bo_move_sync_cleanup(struct ttm_buffer_object *bo,
 			      struct ttm_resource *new_mem);
+void ttm_bo_move_null_drop_tt(struct ttm_buffer_object *bo,
+			      struct ttm_resource *new_mem);
 int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo);
 pgprot_t ttm_io_prot(struct ttm_buffer_object *bo, struct ttm_resource *res,
 		     pgprot_t tmp);

-- 
2.56.0

  parent reply	other threads:[~2026-11-07 17:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-07 17:26 [PATCH 0/3] Spurious OOM with P2P dma-buf imports on multi-GPU systems Matthew Auld
2026-11-07 17:26 ` [PATCH 1/3] drm/xe: don't allocate fake mmap offsets for imported dma-bufs Matthew Auld
2026-11-07 17:43   ` sashiko-bot
2026-11-07 17:26 ` [PATCH 2/3] drm/xe: Exclude imported dma-buf BOs from the TT budget Matthew Auld
2026-11-07 17:36   ` sashiko-bot
2026-11-07 17:26 ` Matthew Auld [this message]
2026-11-07 17:36 ` ✓ CI.KUnit: success for Spurious OOM with P2P dma-buf imports on multi-GPU systems Patchwork
2026-11-07 18:10 ` ✓ Xe.CI.BAT: " Patchwork
2026-11-08  8:22 ` ✓ Xe.CI.FULL: " 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=20261107-oom-fun-v1-3-be9eb05b82ed@intel.com \
    --to=matthew.auld@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=thomas.hellstrom@linux.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.