mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Adrián Larumbe" <adrian.larumbe@collabora.com>
To: Andrew Morton <akpm@linux-foundation.org>,
	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>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	Rob Herring <robh@kernel.org>,
	Steven Price <steven.price@arm.com>,
	Liviu Dudau <liviu.dudau@arm.com>
Cc: kernel@collabora.com,
	"Adrián Larumbe" <adrian.larumbe@collabora.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: [RFC PATCH v2 0/6] Introduce sparse DRM shmem object allocations
Date: Wed, 26 Mar 2025 02:14:20 +0000	[thread overview]
Message-ID: <20250326021433.772196-1-adrian.larumbe@collabora.com> (raw)

This patch series is a proposal for implementing sparse page allocations
for shmem objects. It was initially motivated by a kind of BO managed by
the Panfrost driver, the tiler heap, which grows on demand every time the
GPU faults on a virtual address within its drm_mm-managed ranged.

Because keeping a struct page pointer array that can describe the entire
virtual range is wasteful when only a few backing pages have been
allocated, at Collabora we thought a sparse allocation approach with
xarrays was a more efficient choice.

Since sparse and 'dense' DRM shmem objects must be managed slightly
differently, the API is expanded to allow client drivers to create sparse
objects and also to expand their page backing range, but everything else
should remain as transparent as possible and be handled from within the DRM
shmem system itself.

Discussion of previus revision can be found here:
https://lore.kernel.org/dri-devel/20250218232552.3450939-1-adrian.larumbe@collabora.com/

Changelog:
 v2:
  - Removed patch with helper for non-blocking shmem page allocations.
  - Moved page_array definitions away from scatterlist interface to hide
  them from consumers.
  - Refactored sg_alloc_append_table_from_pages() so that it now calls
  sg_alloc_append_table_from_page_array() to avoid code duplication.
  - Undid extension of __drm_gem_shmem_create() argument list so that a sparse
  shmem object is now fully defined in a parent function.
  - Moved check for absence of backing pages when putting an object into
  drm_gem_shmem_put_pages()
  - Added explanatory comments above DRM WARN'ings across yet unimplemented
  shmem code paths, like kernel vmap's and UM mappings of sparse objects
  - Created drm_gem helper for doing the actual sparse allocation, to keep
  the interface aligned with the existing one with regular shmem objects.
  - Split the body of drm_gem_shmem_get_sparse_pages_locked() into two separate
  functions, one which performs the actual page allocation, and another
  one that retrieves an sgtable.
  - Expanded the argument list of drm_gem_shmem_get_sparse_pages() and its
  children functions so that it takes an gfp mask, in the even that we would
  want to do non-blocking allocations, for instance like when we wish to
  avoid races with the shrinker memory reclaim path.
  - Created shmem helper that returns whether an shmem object has any backing pages.

TODO:
The following items need to be worked on, and will be the subject of a v3 of this RFC:

 - Handle the special case when some of the pages in a sparse allocation range are
   already present, rather than bailing out immediately.
 - Redefining panfrost_gem_object::sgts into an xarray or perhaps a sg_append_table
   to avoid memory waste in allocating more sgtable pointers than we could need.
 - Deciding on the rules for sparse shmem object's kmaps and UM maps.

Adrián Larumbe (6):
  lib/scatterlist.c: Support constructing sgt from page xarray
  drm/shmem: Introduce the notion of sparse objects
  drm/shmem: Implement sparse allocation of pages for shmem objects
  drm/panfrost: Use shmem sparse allocation for heap BOs
  drm/shmem: Add a helper to check object's page backing status
  drm/panfrost/panthor: Take sparse objects into account for fdinfo

 drivers/gpu/drm/drm_gem.c               | 117 +++++++++++
 drivers/gpu/drm/drm_gem_shmem_helper.c  | 264 +++++++++++++++++++++++-
 drivers/gpu/drm/panfrost/panfrost_gem.c |  14 +-
 drivers/gpu/drm/panfrost/panfrost_gem.h |   2 +-
 drivers/gpu/drm/panfrost/panfrost_mmu.c |  86 ++------
 drivers/gpu/drm/panthor/panthor_gem.c   |   2 +-
 include/drm/drm_gem.h                   |   6 +
 include/drm/drm_gem_shmem_helper.h      |  29 ++-
 include/linux/scatterlist.h             |  17 ++
 lib/scatterlist.c                       | 175 +++++++++++-----
 10 files changed, 579 insertions(+), 133 deletions(-)


base-commit: 2f9d51740cc30e0d2c8a23a55b1e20cf2513c250
--
2.48.1

             reply	other threads:[~2025-03-26  2:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-26  2:14 Adrián Larumbe [this message]
2025-03-26  2:14 ` [RFC PATCH v2 1/6] lib/scatterlist.c: Support constructing sgt from page xarray Adrián Larumbe
2025-04-01  8:28   ` Boris Brezillon
2025-03-26  2:14 ` [RFC PATCH v2 2/6] drm/shmem: Introduce the notion of sparse objects Adrián Larumbe
2025-04-01  8:45   ` Boris Brezillon
2025-03-26  2:14 ` [RFC PATCH v2 3/6] drm/shmem: Implement sparse allocation of pages for shmem objects Adrián Larumbe
2025-03-26 19:54   ` Dmitry Osipenko
2025-04-01  9:36   ` Boris Brezillon
2025-03-26  2:14 ` [RFC PATCH v2 4/6] drm/panfrost: Use shmem sparse allocation for heap BOs Adrián Larumbe
2025-03-26  2:14 ` [RFC PATCH v2 5/6] drm/shmem: Add a helper to check object's page backing status Adrián Larumbe
2025-03-31  7:15   ` Thomas Zimmermann
2025-03-26  2:14 ` [RFC PATCH v2 6/6] drm/panfrost/panthor: Take sparse objects into account for fdinfo Adrián Larumbe
2025-04-01  9:39   ` Boris Brezillon
2025-03-31  7:13 ` [RFC PATCH v2 0/6] Introduce sparse DRM shmem object allocations Thomas Zimmermann
2025-03-31  8:31   ` Boris Brezillon
2025-03-31  9:12     ` Thomas Zimmermann

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=20250326021433.772196-1-adrian.larumbe@collabora.com \
    --to=adrian.larumbe@collabora.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=boris.brezillon@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liviu.dudau@arm.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robh@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=steven.price@arm.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

all inboxes | Powered by JetHome®