All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "Adrián Larumbe" <adrian.larumbe@collabora.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Rob Herring" <robh@kernel.org>,
	"Steven Price" <steven.price@arm.com>,
	"Liviu Dudau" <liviu.dudau@arm.com>,
	kernel@collabora.com, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org
Subject: Re: [RFC PATCH v2 0/6] Introduce sparse DRM shmem object allocations
Date: Mon, 31 Mar 2025 10:31:02 +0200	[thread overview]
Message-ID: <20250331103102.22be5363@collabora.com> (raw)
In-Reply-To: <c1809502-e9b7-43f7-9d88-0e615bf1ff94@suse.de>

Hi Thomas,

On Mon, 31 Mar 2025 09:13:59 +0200
Thomas Zimmermann <tzimmermann@suse.de> wrote:

> Hi
> 
> Am 26.03.25 um 03:14 schrieb Adrián Larumbe:
> > 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.  
> 
> I've looked at panfrost_gem.h and found that the driver's gem structure 
> has grown quite a bit. It seems to have outgrown gem-shmem already.  I 
> think you should consider pulling a copy of gem-shmem into the driver 
> and building a dedicated memory manager on top.

Actually, it's not just something we need for panfrost. I plan to use
the same non-blocking allocation mechanism for panthor's heap
chunks/buffers, and lima could use it for its heap buffers too. The
non-blocking page allocation is also something i915 has been
open-coding here [1], and I believe that some of this logic could
(and should IMHO) live in common code rather than each driver coming
with its own solution, thus increasing the risk of bugs/inconsistencies.
That's even more important if we provide a common gem-shmem shrinker
like Dmitry's has been proposing.

Best Regards,

Boris

[1]https://elixir.bootlin.com/linux/v6.13.7/source/drivers/gpu/drm/i915/gem/i915_gem_shmem.c#L89

  reply	other threads:[~2025-03-31  8:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-26  2:14 [RFC PATCH v2 0/6] Introduce sparse DRM shmem object allocations Adrián Larumbe
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 [this message]
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=20250331103102.22be5363@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=adrian.larumbe@collabora.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --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 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.