AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Honglei Huang <honghuan@amd.com>
To: <matthew.brost@intel.com>, <sima@ffwll.ch>,
	<rodrigo.vivi@intel.com>, <thomas.hellstrom@linux.intel.com>,
	<himal.prasad.ghimiray@intel.com>, <dakr@kernel.org>,
	<intel-xe@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>
Cc: <aliceryhl@google.com>, <Alexander.Deucher@amd.com>,
	<Felix.Kuehling@amd.com>, <Christian.Koenig@amd.com>,
	<Ray.Huang@amd.com>, <Junhua.Shen@amd.com>,
	<amd-gfx@lists.freedesktop.org>, <honghuan@amd.com>
Subject: [PATCH v4 0/6] drm/gpusvm: share one HMM fault and keep single mappings inline
Date: Sat, 5 Sep 2026 21:31:36 +0800	[thread overview]
Message-ID: <20260905133142.3628027-1-honghuan@amd.com> (raw)

Patches 1 to 4 are the get_pages() split already posted as v2. Patches 5
and 6 implement the dma_addr storage optimization Matt suggested in [6].
They build on the DMA paths v2 reworks, so they are sent in the same
series; I can split them out if that is preferred.

drm_gpusvm_get_pages() does two things at once: the MM level HMM fault
of the CPU range, and the device DMA mapping of the faulted pages. When
one CPU range is mirrored on several devices, every device has to call
get_pages() and redo the HMM fault. Matt suggested [2] passing an array
of drm_gpusvm_pages plus a count so the fault is taken once and shared,
while the notifier retry loop stays in common code so drivers never open
code it.

For patches 5 and 6, the focus is on optimizing the storage of DMA
addresses for THP pages and IOVA mapped ranges. get_pages() sizes
dma_addr for the worst case of one entry per page, but the mapping loop
advances by page order, so a 2 MiB THP holds an 8 KiB array with 16
bytes of address in it. Patch 5 keeps that single mapping inline. Patch
6 extends the optimization to IOVA mapped ranges, where contiguous
device addresses allow for a similar inline approach.

A range folds only when one drm_pagemap_addr describes all of it, which
leaves three shapes not included:
  - Mixed device and system pages: the device addresses come from
    device_map(), outside the IOVA reservation, so they are not
    contiguous. Not included for inline storage.
  - Mixed orders: contiguous under IOVA and foldable in principle, but
    one entry carries one order; expressing two needs an entry count or
    a segment iterator. Needs additional handling for mixed orders.
    So not included for this inline storage change.
  - Several huge entries: needs a chunk larger than PMD size, which no
    consumer configures today.

Patches overview:
  - patch 1 moves the dma_addr allocation out of the notifier locked
    section, so the mapping step becomes self contained.
  - patch 2 pulls the per-device mapping loop into
    drm_gpusvm_dma_map_pages(). Code motion only.
  - patch 3 makes get_pages() take an array of drm_gpusvm_pages plus a
    count: fault once, then DMA map each instance, one per owning
    drm_device, under a single notifier retry gate. Instances that are
    already mapped are skipped, so an -EAGAIN retry does not redo them.
    The common 1:1 case passes count == 1 and is unchanged.
  - patch 4 adds a no_dma_map context flag so a driver that only needs
    the CPU pages faulted in can skip the device DMA mapping.
  - patch 5: keeps a single mapping inline for THP.
  - patch 6: extends that to IOVA mapped ranges.

v2:
  - Rebased on drm-tip.
  - Dropped v1 patch 1 ("drm/gpusvm: extract drm_gpusvm_hmm_fault()
    helper"), it is part of [3] now.
  - patch 3: drm_gpusvm_pages_valid_unlocked() takes the array and the
    count itself, instead of get_pages() open coding an all_valid loop.
  - patch 3: fixed the N:1 doc example, it used the wrong union member
    when the count is 1. Added a driver_pages() accessor.
  - patch 3: documented that on error the instances mapped before the
    failing one stay mapped, the caller must unmap and free all of them.
  - patch 4: reject no_dma_map together with devmem_only, without the
    DMA mapping step there is no page type check to enforce it.
  - patch 4: documented that no_dma_map only returns a snapshot, the
    caller must recheck mmu_interval_read_retry() itself.

V3:
 - Patch 3: check svm_pages[0].flags.unmapped instead of walking every
   instance, per Matt's review. drm_gpusvm_range_set_unmapped() flags
   the whole array in one go under the write lock, so any instance
   answers for all of them.
 - Patch 3: reject a zero page count instead of relying on the caller.
 - Patch 5: new, keeps a single mapping inline for THP.
 - Patch 6: new, extends that to IOVA mapped range.
 - Add Reviewed-by Matt in patches 1, 2 and 4.

V4:
 - Patch 5: add xe_svm_range_first_dma(), with a stub for the
   CONFIG_DRM_XE_GPUSVM disabled build, so xe_pt_stage_bind() type
   checks in both configurations. Reported by Intel CI [7].
 - Patch 6: the wrapper hands out the contiguous flag too, and the stub
   clears it.
 - Add Reviewed-by Matt in patch 3.

tests:
AMDGPU:
  SVM:DRM N:1 multi device support is work in progress on top of this
  series. The single device (1:1) path was tested with the amdgpu SVM
  adaptation on top. Based on amdgpu SVM [4].
  Tested on gfx906 (MI60) with XNACK on, in three configurations:
  THP ON + IOVA ON, THP ON + IOVA OFF, NO THP + NO IOVA.
  - KFD test: SVM all passed except the get attr refactor.
  - ROCR test: all passed.
  - HIP catch test: gfx943 (MI300X): 99% passed.
                    gfx906 (MI60): 99% passed.

links:
[1] drm_gpusvm_pages decoupling series:
    https://lore.kernel.org/amd-gfx/20260630102127.392396-1-honghuan@amd.com/
[2] Matt's suggested direction:
    https://lore.kernel.org/amd-gfx/aijdg7RWwrEDEMxC@gsse-cloud1.jf.intel.com/
[3] drm/gpusvm: use hmm_range_fault_unlocked_timeout() for range faults:
    https://lore.kernel.org/20260723-hmm-v10-v11-8-c55b003a4b61@gmail.com
[4] amdgpu SVM:
    https://lore.kernel.org/amd-gfx/20260804094246.1719318-1-ray.huang@amd.com/
[5] v2 of this series:
    https://lore.kernel.org/amd-gfx/20260901090100.2024933-1-honghuan@amd.com/
[6] Matt on keeping the dma address inline:
    https://lore.kernel.org/amd-gfx/apcp%2FXJpPdG3jzPd@gsse-cloud1.jf.intel.com/
[7] Intel CI build report on v3:
    https://patchwork.freedesktop.org/series/173405/

Honglei Huang (6):
  drm/gpusvm: move dma_addr allocation before the notifier lock
  drm/gpusvm: extract drm_gpusvm_dma_map_pages() helper
  drm/gpusvm: let drm_gpusvm_get_pages() map an array of pages
  drm/gpusvm: make the DMA mapping step in get_pages() optional
  drm/gpusvm: keep a single DMA mapping inline for THP
  drm/gpusvm: keep an IOVA mapped range dma address inline

 drivers/gpu/drm/drm_gpusvm.c       | 406 +++++++++++++++++++++--------
 drivers/gpu/drm/xe/xe_pt.c         |  22 +-
 drivers/gpu/drm/xe/xe_res_cursor.h |   5 +-
 drivers/gpu/drm/xe/xe_svm.c        |   2 +-
 drivers/gpu/drm/xe/xe_svm.h        |  20 ++
 drivers/gpu/drm/xe/xe_userptr.c    |   2 +-
 include/drm/drm_gpusvm.h           |  71 ++++-
 7 files changed, 400 insertions(+), 128 deletions(-)


base-commit: 313da1cc22491f07075c7ae36372343aa235d11e
-- 
2.34.1


             reply	other threads:[~2026-09-05 13:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-05 13:31 Honglei Huang [this message]
2026-09-05 13:31 ` [PATCH v4 1/6] drm/gpusvm: move dma_addr allocation before the notifier lock Honglei Huang
2026-09-05 13:31 ` [PATCH v4 2/6] drm/gpusvm: extract drm_gpusvm_dma_map_pages() helper Honglei Huang
2026-09-05 13:31 ` [PATCH v4 3/6] drm/gpusvm: let drm_gpusvm_get_pages() map an array of pages Honglei Huang
2026-09-05 13:31 ` [PATCH v4 4/6] drm/gpusvm: make the DMA mapping step in get_pages() optional Honglei Huang
2026-09-05 13:31 ` [PATCH v4 5/6] drm/gpusvm: keep a single DMA mapping inline for THP Honglei Huang
2026-09-08  3:12   ` Matthew Brost
2026-09-05 13:31 ` [PATCH v4 6/6] drm/gpusvm: keep an IOVA mapped range dma address inline Honglei Huang
2026-09-08  3:18   ` Matthew Brost
2026-09-08  3:49     ` Matthew Brost
2026-09-08  5:40       ` Huang, Honglei

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=20260905133142.3628027-1-honghuan@amd.com \
    --to=honghuan@amd.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=Felix.Kuehling@amd.com \
    --cc=Junhua.Shen@amd.com \
    --cc=Ray.Huang@amd.com \
    --cc=aliceryhl@google.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.brost@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sima@ffwll.ch \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox