dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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,
	"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 02/33] drm/ttm/pool: Add ttm_pool_page_order_nodma() helper
Date: Sat, 11 Jul 2026 05:40:39 -0700	[thread overview]
Message-ID: <alI5xwo67h9oViGh@gsse-cloud1.jf.intel.com> (raw)
In-Reply-To: <7e1a098e-927e-4dc5-85fc-c7081c0c10c9@amd.com>

On Sat, Jul 11, 2026 at 12:39:38PM +0200, Christian König wrote:
> On 7/10/26 23:54, Matthew Brost wrote:
> > TTM records the allocation order of a multi-order page in page->private at
> > allocation time. For pools that do not use dma_alloc the order is stored
> > directly, while dma_alloc pools store a struct ttm_pool_dma pointer there
> > instead. Drivers that do their own DMA mapping (e.g. Xe) need the per-page
> > order to walk a populated ttm_tt one chunk at a time, but cannot rely on
> > folio_order(): TTM allocates high-order pages with alloc_pages_node()
> > without __GFP_COMP, so they are not compound and folio_order() always
> > returns 0.
> 
> Well what is the justification of XE doing the DMA mapping themselves?
> 

This maps to `TTM_ALLOCATION_POOL_USE_DMA_ALLOC`, which is clear in Xe, so
we use this helper function to determine the page order in various
places. I exported this because I'd want to have fish out the pool and
use ttm_pool_page_order.

That said, Xe also owns the DMA mappings. To be honest, I didn't realize
`ttm_sg_tt_init()` was commonly used, but having Xe manage DMA mappings
has several advantages (I believe we inherited this part from Faith /
Dave PoC work on Xe):

- Using an SG list or IOVA allocation gives smaller pages a contiguous
  address space, which can then be mapped using larger GPU pages.
- SG list or IOVA mapping requires only a single IOMMU sync for a
  collection of pages, whereas each `dma_map_page()` or `dma_unmap_page`
  call requires its own IOMMU synchronization.
- Using IOVA mapping (later in the series) allows individual page
  linkages to be replaced without modifying the IOVA programmed into the
  GPU page tables.

The second point is a fairly significant performance issue. I recently
switched GPUSVM over to `dma_iova_alloc()`, and if I recall correctly, a
chain of mappings with a single synchronization was roughly 100x faster
than individual `dma_map_page()` calls for a 2 MiB region backed by 4 KiB
pages.

It should not be quite as severe in TTM, since it generally does not use
lower-order pages, but mapping something like a 32 MiB BO will still be
significantly faster when using an SG list or IOVA allocation.

The TTM core should really be fixed in this area, or drivers should at
least be encouraged not to use this path, since implementing the mapping
on the driver side is fairly trivial.

Matt

> Regards,
> Christian.
> 
> > 
> > Expose ttm_pool_page_order_nodma(), a thin wrapper that returns the order
> > recorded in page->private. It is only valid for pages from a pool that does
> > not use dma_alloc; whether a TTM device uses dma_alloc is fixed at ttm
> > device init time, so callers know from their device configuration that this
> > helper applies. Use it from the existing internal ttm_pool_page_order() to
> > keep a single source of truth.
> > 
> > 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>
> > Assisted-by: GitHub_Copilot:claude-opus-4.8
> > Signed-off-by: Matthew Brost <matthew.brost@intel.com>
> > ---
> >  drivers/gpu/drm/ttm/ttm_pool.c | 25 ++++++++++++++++++++++++-
> >  include/drm/ttm/ttm_pool.h     |  2 ++
> >  2 files changed, 26 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
> > index dbe977412a81..d34592d4dbc7 100644
> > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > @@ -461,6 +461,29 @@ static unsigned int ttm_pool_shrink(int nid, unsigned long num_to_free)
> >  	return num_pages;
> >  }
> >  
> > +/**
> > + * ttm_pool_page_order_nodma() - Allocation order of a non-dma_alloc TTM page
> > + * @p: The page to query.
> > + *
> > + * Return the allocation order that the TTM pool allocator recorded in
> > + * @p->private at allocation time. This only works for pages that were
> > + * allocated from a pool which does *not* use dma_alloc (i.e. pages backed by
> > + * alloc_pages_node()), where TTM stores the order directly in page->private.
> > + *
> > + * For dma_alloc pools, page->private instead holds a struct ttm_pool_dma
> > + * pointer and this helper must not be used. Whether a TTM device uses
> > + * dma_alloc is fixed at ttm device init time, so callers are expected to know
> > + * from their TTM device configuration that their pages are not dma_alloc
> > + * backed before using this helper.
> > + *
> > + * Return: The allocation order of the page.
> > + */
> > +unsigned int ttm_pool_page_order_nodma(struct page *p)
> > +{
> > +	return p->private;
> > +}
> > +EXPORT_SYMBOL(ttm_pool_page_order_nodma);
> > +
> >  /* Return the allocation order based for a page */
> >  static unsigned int ttm_pool_page_order(struct ttm_pool *pool, struct page *p)
> >  {
> > @@ -470,7 +493,7 @@ static unsigned int ttm_pool_page_order(struct ttm_pool *pool, struct page *p)
> >  		return dma->vaddr & ~PAGE_MASK;
> >  	}
> >  
> > -	return p->private;
> > +	return ttm_pool_page_order_nodma(p);
> >  }
> >  
> >  /*
> > diff --git a/include/drm/ttm/ttm_pool.h b/include/drm/ttm/ttm_pool.h
> > index 26ee592e1994..753203980e2c 100644
> > --- a/include/drm/ttm/ttm_pool.h
> > +++ b/include/drm/ttm/ttm_pool.h
> > @@ -94,6 +94,8 @@ long ttm_pool_backup(struct ttm_pool *pool, struct ttm_tt *ttm,
> >  int ttm_pool_restore_and_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
> >  			       const struct ttm_operation_ctx *ctx);
> >  
> > +unsigned int ttm_pool_page_order_nodma(struct page *p);
> > +
> >  int ttm_pool_mgr_init(unsigned long num_pages);
> >  void ttm_pool_mgr_fini(void);
> >  
> 

  reply	other threads:[~2026-07-11 12:40 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 [this message]
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

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=alI5xwo67h9oViGh@gsse-cloud1.jf.intel.com \
    --to=matthew.brost@intel.com \
    --cc=airlied@gmail.com \
    --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