From: Matthew Brost <matthew.brost@intel.com>
To: "Christian König" <christian.koenig@amd.com>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
amd-gfx@lists.freedesktop.org,
"Alex Deucher" <alexander.deucher@amd.com>,
"Carlos Santa" <carlos.santa@intel.com>,
"Ryan Neph" <ryanneph@google.com>,
"Huang Rui" <ray.huang@amd.com>,
"Matthew Auld" <matthew.auld@intel.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
linux-kernel@vger.kernel.org,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>
Subject: Re: [PATCH v2 00/33] drm/ttm, drm/xe: Minimize dma-resv hold times and defragment sub-optimally backed BOs
Date: Sat, 11 Jul 2026 06:49:16 -0700 [thread overview]
Message-ID: <alJJ3CensWXW+Wa7@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <971f7948-b241-46cc-980f-61df43af22bd@amd.com>
On Sat, Jul 11, 2026 at 12:33:20PM +0200, Christian König wrote:
> On 7/10/26 23:54, Matthew Brost wrote:
> > The overarching goal of this series is to keep user-facing IOCTLs snappy
> > by holding the BO dma-resv lock for the shortest possible time, and to
> > push the expensive, best-effort work - page (re)allocation, DMA mapping
> > and placement fixups - into the background or out of the locked critical
> > section entirely.
> >
> > Two related mechanisms fall out of that goal:
> >
> > - Out-of-lock backing. Page allocation and DMA mapping are the dominant
> > cost of gem_create and of BO moves, and doing them under the dma-resv
> > lock serializes otherwise-independent clients.
>
> Saying that doesn't make sense.
>
> The DMA-resv lock is either per BO or per VM and so the clients are not even remotely independent of that lock.
>
s/clients/threads:
Same VM:
Thread A - allocate memory under VM's dma-resv, takes a very long time
Thread B - tries to submit, blocks on Thread A
> > This series preallocates
> > the backing pages (and, where applicable, builds the DMA/IOVA mapping)
> > outside the lock, then transfers the result into the BO under a brief
> > lock hold. The user gets a fast IOCTL return; the heavy lifting happens
> > without contending the reservation.
>
> Ok, that sounds like a really bad idea.
>
> Why in the world would you do this? The dma_resv lock is exactly what is used to prevent something like that.
>
Allocating pages from the core MM subsystem does not really have anything to do
with dma_resv. Moving pages attached to a BO, however, is related to dma_resv,
and that is where TTM comes into play.
The TL;DR is that a defragmenter does not work well when page allocations are
performed while holding the dma_resv lock. During the v1 implementation, I
quickly noticed that the dma_resv lock could be held for up to 100 ms in the
worst case, and more typically for 5–10 ms. When the frame budget at 60 Hz is
only 16 ms, this is obviously a problem, and it becomes even more problematic at
higher refresh rates.
After quite a bit of work, the common-case lock hold time is now below 100 µs,
while the worst case is under 1 ms. At that point, a defragmenter becomes much
more viable.
I'm applying the same defragmentation logic to IOCTLs. Why hold the lock any
longer than necessary and introduce additional pipeline stalls?
> >
> > - Page defragmentation. A BO allocated under memory pressure keeps its
> > scattered, sub-optimally-ordered backing for its entire lifetime,
> > costing TLB efficiency forever. TTM grows the plumbing to track
> > order-failure and to re-back a populated BO in place at the beneficial
> > order, and Xe wires up a background delayed worker that promotes such
> > BOs on the GPU once memory is available again - again, off the hot
> > path and without stalling the submitting thread.
>
> That could be quite beneficial, but so far falling back to low order allocation was only seen as last resort to avoid OOM.
>
Right now, the situation is effectively "once placed badly, forever placed
badly."
Matt
> Regards,
> Christian.
>
> >
> > Since v1 [1] the series has grown considerably. The bulk of the new
> > material is a direct result of profiling: once the defragmenter was in
> > place, the remaining dma-resv hold times and the per-BO
> > allocation/mapping costs showed up clearly, which motivated the
> > out-of-lock preallocation, the IOVA-based mapping path, and the amdgpu
> > counterpart. Rather than land the defragmenter alone, v2 folds in these
> > optimizations since they share the same infrastructure and the same
> > "hold dma-resv briefly, fix up in the background" architecture.
> >
> > The series is organized in sections rather than described patch by patch:
> >
> > - Patches 1-10 (drm/ttm): core TTM preparation - order-failure tracking,
> > the defragmentation move, reclaim backoff, and out-of-lock page
> > preallocation plumbing.
> > - Patches 11-14: other dependent drm/gpusvm and drm/xe patches this
> > series builds on (DMA-mapping accounting, per-order DMA stats, async
> > L2 flush, and a VM-teardown ordering fix).
> > - Patches 15-23 (drm/xe): the page defragmenter itself - BO tracking,
> > the on-GPU defrag copy, xe_bo_move() handling, and the background
> > worker with its stats and configuration.
> > - Patches 24-25 (drm/xe): out-of-lock system BO backing preallocation
> > in gem_create, moving page allocation out of the dma-resv lock.
> > - Patches 26-32 (drm/xe): IOVA-based DMA mapping optimizations, building
> > and finalizing the mapping outside the lock.
> > - Patch 33 (drm/amdgpu): the equivalent out-of-lock system BO
> > preallocation for amdgpu, exercising the shared TTM plumbing.
> >
> > Testing
> > =======
> >
> > - 3D benchmarks on Ubuntu and on Android, with memory intentionally
> > fragmented by a separate program at launch (plus beneficial-order
> > error injection). BOs are initially backed at a sub-optimal order and
> > scores start lower; the background defrag worker then promotes the
> > backing to the beneficial order and scores climb back in line with the
> > unfragmented baseline.
> > - IGT:
> > https://patchwork.freedesktop.org/patch/739052/?series=170046&rev=2
> >
> > Matt
> >
> > [1] https://patchwork.freedesktop.org/series/169053/
> >
> > Cc: amd-gfx@lists.freedesktop.org
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Carlos Santa <carlos.santa@intel.com>
> > Cc: Ryan Neph <ryanneph@google.com>
> > Cc: Christian Koenig <christian.koenig@amd.com>
> > Cc: Huang Rui <ray.huang@amd.com>
> > Cc: Matthew Auld <matthew.auld@intel.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Maxime Ripard <mripard@kernel.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: David Airlie <airlied@gmail.com>
> > Cc: Simona Vetter <simona@ffwll.ch>
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-kernel@vger.kernel.org
> > Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> >
> >
> >
> > Matthew Brost (31):
> > drm/ttm/pool: Allow backing off reclaim at the beneficial order
> > drm/ttm/pool: Add ttm_pool_page_order_nodma() helper
> > drm/ttm: Record sub-optimal page order allocations in ttm_tt
> > drm/ttm: Introduce ttm_pool_alloc_iter for __ttm_pool_alloc()
> > drm/ttm: Support defragmentation moves
> > drm/ttm: Add fault injection for beneficial-order allocation failures
> > drm/ttm: Harvest beneficial-order pages on defragmentation moves
> > drm/ttm: Bound page (re)allocation per defragmentation move
> > drm/ttm: Preallocate beneficial-order defrag pages outside the lock
> > drm/ttm: Add full out-of-lock preallocation for ttm_pool_alloc()
> > drm/xe: Flush L2 asynchronously in xe_bo_trigger_rebind()
> > drm/xe: Destroy page tables after unlinking all VMAs on VM close
> > drm/xe: Track BOs backed at a sub-optimal page order
> > drm/xe: Back off beneficial-order reclaim under defrag pressure
> > drm/xe: Add xe_migrate_copy_defrag() for on-GPU defrag copies
> > drm/xe: Handle defrag moves in xe_bo_move()
> > drm/xe: Skip self-copies for borrowed pages on defrag moves
> > drm/xe: Add a page defragmentation worker
> > drm/xe: Add defrag GT stats
> > drm/xe: Add Kconfig.profile options for BO defrag configuration
> > drm/xe: Defrag using out-of-lock page preallocation
> > drm/xe: Add defrag profiling tracepoints
> > drm/xe: Preallocate system BO backing outside the dma-resv lock
> > drm/xe: Add tracepoint for xe_gem_create_ioctl
> > drm/xe: Add IOVA-based xe_res_cursor variant
> > drm/xe: Use IOVA-based DMA mapping for eligible tt BOs
> > drm/xe: Add per-device dependency scheduler for IOVA defrag finalize
> > drm/xe: Add packed copy-step IOVA mapping for defrag
> > drm/xe: Blit src-natural to dst-packed for defrag-IOVA copies
> > drm/xe: Finalize defrag-IOVA moves with post-copy job
> > drm/amdgpu: Preallocate system BO pages outside the reservation lock
> >
> > Thomas Hellström (2):
> > drm/gpusvm: Add a DMA-mapping accounting callback
> > drm/xe: Add debugfs stats for DMA-mapped pages per order
> >
> > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 45 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_gem.h | 5 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 4 +
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 39 +-
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 3 +
> > drivers/gpu/drm/drm_gpusvm.c | 17 +-
> > drivers/gpu/drm/ttm/ttm_bo.c | 101 +-
> > drivers/gpu/drm/ttm/ttm_bo_util.c | 21 +-
> > drivers/gpu/drm/ttm/ttm_pool.c | 931 +++++++++-
> > drivers/gpu/drm/ttm/ttm_tt.c | 67 +
> > drivers/gpu/drm/xe/Kconfig.profile | 40 +
> > drivers/gpu/drm/xe/tests/xe_bo.c | 8 +-
> > drivers/gpu/drm/xe/tests/xe_dma_buf.c | 2 +-
> > drivers/gpu/drm/xe/tests/xe_migrate.c | 12 +-
> > drivers/gpu/drm/xe/xe_bo.c | 1632 ++++++++++++++++-
> > drivers/gpu/drm/xe/xe_bo.h | 15 +-
> > drivers/gpu/drm/xe/xe_bo_types.h | 6 +
> > drivers/gpu/drm/xe/xe_debugfs.c | 26 +
> > drivers/gpu/drm/xe/xe_device.c | 35 +
> > drivers/gpu/drm/xe/xe_device_types.h | 57 +
> > drivers/gpu/drm/xe/xe_dma_buf.c | 2 +-
> > drivers/gpu/drm/xe/xe_ggtt.c | 2 +-
> > drivers/gpu/drm/xe/xe_gt_stats.c | 5 +
> > drivers/gpu/drm/xe/xe_gt_stats_types.h | 17 +
> > drivers/gpu/drm/xe/xe_migrate.c | 531 +++++-
> > drivers/gpu/drm/xe/xe_migrate.h | 17 +
> > drivers/gpu/drm/xe/xe_pt.c | 2 +-
> > drivers/gpu/drm/xe/xe_res_cursor.h | 56 +-
> > drivers/gpu/drm/xe/xe_svm.c | 36 +-
> > drivers/gpu/drm/xe/xe_svm.h | 3 +-
> > drivers/gpu/drm/xe/xe_trace_bo.h | 90 +
> > drivers/gpu/drm/xe/xe_userptr.c | 55 +
> > drivers/gpu/drm/xe/xe_userptr.h | 1 +
> > drivers/gpu/drm/xe/xe_vm.c | 149 +-
> > drivers/gpu/drm/xe/xe_vm.h | 5 +
> > include/drm/drm_gpusvm.h | 19 +
> > include/drm/ttm/ttm_bo.h | 64 +
> > include/drm/ttm/ttm_pool.h | 46 +
> > include/drm/ttm/ttm_tt.h | 43 +-
> > 42 files changed, 4029 insertions(+), 189 deletions(-)
> >
>
prev parent reply other threads:[~2026-07-11 13:49 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 21:54 [PATCH v2 00/33] drm/ttm, drm/xe: Minimize dma-resv hold times and defragment sub-optimally backed BOs Matthew Brost
2026-07-10 21:54 ` [PATCH v2 01/33] drm/ttm/pool: Allow backing off reclaim at the beneficial order Matthew Brost
2026-07-10 22:08 ` sashiko-bot
2026-07-11 10:38 ` Christian König
2026-07-11 13:27 ` Matthew Brost
2026-07-10 21:54 ` [PATCH v2 02/33] drm/ttm/pool: Add ttm_pool_page_order_nodma() helper Matthew Brost
2026-07-11 10:39 ` Christian König
2026-07-11 12:40 ` Matthew Brost
2026-07-10 21:54 ` [PATCH v2 03/33] drm/ttm: Record sub-optimal page order allocations in ttm_tt Matthew Brost
2026-07-10 21:54 ` [PATCH v2 04/33] drm/ttm: Introduce ttm_pool_alloc_iter for __ttm_pool_alloc() Matthew Brost
2026-07-10 22:03 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 05/33] drm/ttm: Support defragmentation moves Matthew Brost
2026-07-10 22:09 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 06/33] drm/ttm: Add fault injection for beneficial-order allocation failures Matthew Brost
2026-07-10 21:54 ` [PATCH v2 07/33] drm/ttm: Harvest beneficial-order pages on defragmentation moves Matthew Brost
2026-07-10 22:19 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 08/33] drm/ttm: Bound page (re)allocation per defragmentation move Matthew Brost
2026-07-10 22:17 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 09/33] drm/ttm: Preallocate beneficial-order defrag pages outside the lock Matthew Brost
2026-07-10 22:09 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 10/33] drm/ttm: Add full out-of-lock preallocation for ttm_pool_alloc() Matthew Brost
2026-07-10 21:54 ` [PATCH v2 11/33] drm/gpusvm: Add a DMA-mapping accounting callback Matthew Brost
2026-07-10 22:10 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 12/33] drm/xe: Add debugfs stats for DMA-mapped pages per order Matthew Brost
2026-07-10 22:23 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 13/33] drm/xe: Flush L2 asynchronously in xe_bo_trigger_rebind() Matthew Brost
2026-07-10 22:18 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 14/33] drm/xe: Destroy page tables after unlinking all VMAs on VM close Matthew Brost
2026-07-10 21:54 ` [PATCH v2 15/33] drm/xe: Track BOs backed at a sub-optimal page order Matthew Brost
2026-07-10 22:18 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 16/33] drm/xe: Back off beneficial-order reclaim under defrag pressure Matthew Brost
2026-07-10 21:54 ` [PATCH v2 17/33] drm/xe: Add xe_migrate_copy_defrag() for on-GPU defrag copies Matthew Brost
2026-07-10 22:17 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 18/33] drm/xe: Handle defrag moves in xe_bo_move() Matthew Brost
2026-07-10 22:25 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 19/33] drm/xe: Skip self-copies for borrowed pages on defrag moves Matthew Brost
2026-07-10 22:18 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 20/33] drm/xe: Add a page defragmentation worker Matthew Brost
2026-07-10 22:24 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 21/33] drm/xe: Add defrag GT stats Matthew Brost
2026-07-10 22:16 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 22/33] drm/xe: Add Kconfig.profile options for BO defrag configuration Matthew Brost
2026-07-10 21:54 ` [PATCH v2 23/33] drm/xe: Defrag using out-of-lock page preallocation Matthew Brost
2026-07-10 22:27 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 24/33] drm/xe: Add defrag profiling tracepoints Matthew Brost
2026-07-10 22:18 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 25/33] drm/xe: Preallocate system BO backing outside the dma-resv lock Matthew Brost
2026-07-10 22:21 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 26/33] drm/xe: Add tracepoint for xe_gem_create_ioctl Matthew Brost
2026-07-10 22:20 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 27/33] drm/xe: Add IOVA-based xe_res_cursor variant Matthew Brost
2026-07-10 22:24 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 28/33] drm/xe: Use IOVA-based DMA mapping for eligible tt BOs Matthew Brost
2026-07-10 21:54 ` [PATCH v2 29/33] drm/xe: Add per-device dependency scheduler for IOVA defrag finalize Matthew Brost
2026-07-10 22:27 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 30/33] drm/xe: Add packed copy-step IOVA mapping for defrag Matthew Brost
2026-07-10 21:54 ` [PATCH v2 31/33] drm/xe: Blit src-natural to dst-packed for defrag-IOVA copies Matthew Brost
2026-07-10 22:30 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 32/33] drm/xe: Finalize defrag-IOVA moves with post-copy job Matthew Brost
2026-07-10 22:36 ` sashiko-bot
2026-07-10 21:54 ` [PATCH v2 33/33] drm/amdgpu: Preallocate system BO pages outside the reservation lock Matthew Brost
2026-07-10 22:29 ` sashiko-bot
2026-07-11 10:33 ` [PATCH v2 00/33] drm/ttm, drm/xe: Minimize dma-resv hold times and defragment sub-optimally backed BOs Christian König
2026-07-11 13:49 ` Matthew Brost [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=alJJ3CensWXW+Wa7@gsse-cloud1.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=carlos.santa@intel.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=mripard@kernel.org \
--cc=ray.huang@amd.com \
--cc=ryanneph@google.com \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tzimmermann@suse.de \
/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