mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: "David Airlie" <airlied@gmail.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Gurchetan Singh" <gurchetansingh@chromium.org>,
	"Chia-I Wu" <olvaffe@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Christian König" <christian.koenig@amd.com>,
	"Qiang Yu" <yuq825@gmail.com>,
	"Steven Price" <steven.price@arm.com>,
	"Emma Anholt" <emma@anholt.net>, "Melissa Wen" <mwen@igalia.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	kernel@collabora.com, virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v14 02/12] drm/shmem-helper: Add pages_pin_count field
Date: Mon, 31 Jul 2023 15:27:31 +0300	[thread overview]
Message-ID: <4c5fa735-9bfd-f92a-8deb-888c7368f89e@collabora.com> (raw)
In-Reply-To: <20230725103234.0c8923f1@collabora.com>

On 7/25/23 11:32, Boris Brezillon wrote:
>> Can we make it an atomic_t, so we can avoid taking the lock when the
>> GEM has already been pinned. That's something I need to be able to grab
>> a pin-ref in a path where the GEM resv lock is already held[1]. We could
>> of course expose the locked version,
> My bad, that's actually not true. The problem is not that I call
> drm_gem_shmem_pin() with the resv lock already held, but that I call
> drm_gem_shmem_pin() in a dma-signaling path where I'm not allowed to
> take a resv lock. I know for sure pin_count > 0, because all GEM objects
> mapped to a VM have their memory pinned right now, and this should
> stand until we decide to add support for live-GEM eviction, at which
> point we'll probably have a way to detect when a GEM is evicted, and
> avoid calling drm_gem_shmem_pin() on it.
> 
> TLDR; I can't trade the atomic_t for a drm_gem_shmem_pin_locked(),
> because that wouldn't solve my problem. The other solution would be to
> add an atomic_t at the driver-GEM level, and only call
> drm_gem_shmem_[un]pin() on 0 <-> 1 transitions, but I thought using an
> atomic at the GEM-shmem level, to avoid locking when we can, would be
> beneficial to the rest of the eco-system. Let me know if that's not an
> option, and I'll go back to the driver-specific atomic_t.

Could you please explain why do you need to pin GEM in a signal handler?
This is not something drivers usually do or need to do. You likely also
shouldn't need to detect that GEM is evicted in yours driver. I'd expect
that Panthor shouldn't differ from Panfrost in regards to how GEM memory
management is done and Panfrost doesn't need to do anything special.

Note that patch #14 makes locked pin/unpin functions public and turns
the unlocked variants into helpers, you'll be able to experiment with
these funcs in the Panthor driver.

In general, using atomic_t or kref should be a good thing to do, but
AFAICS it shouldn't bring benefits to the today's drm-shmem users. I'd
want to understand what you're trying to achieve in the Panthor driver.

-- 
Best regards,
Dmitry


  reply	other threads:[~2023-07-31 12:28 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-22 23:47 [PATCH v14 00/12] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 01/12] drm/shmem-helper: Factor out pages alloc/release from drm_gem_shmem_get/put_pages() Dmitry Osipenko
2023-07-25  7:14   ` Boris Brezillon
2023-07-22 23:47 ` [PATCH v14 02/12] drm/shmem-helper: Add pages_pin_count field Dmitry Osipenko
2023-07-25  7:27   ` Boris Brezillon
2023-07-25  8:32     ` Boris Brezillon
2023-07-31 12:27       ` Dmitry Osipenko [this message]
2023-07-31 12:31         ` Dmitry Osipenko
2023-07-31 13:35         ` Boris Brezillon
2023-08-02  2:31           ` Danilo Krummrich
2023-08-02  9:06             ` Boris Brezillon
2023-07-22 23:47 ` [PATCH v14 03/12] drm/shmem-helper: Switch drm_gem_shmem_vmap/vunmap to use pin/unpin Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 04/12] drm/shmem-helper: Factor out unpinning part from drm_gem_shmem_purge() Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 05/12] drm/shmem-helper: Add memory shrinker Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 06/12] drm/shmem-helper: Remove obsoleted is_iomem test Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 07/12] drm/shmem-helper: Export drm_gem_shmem_get_pages_sgt_locked() Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 08/12] drm/virtio: Support memory shrinking Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 09/12] drm/panfrost: Switch to generic memory shrinker Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 10/12] drm/shmem-helper: Refactor locked/unlocked functions Dmitry Osipenko
2023-07-25  7:47   ` Boris Brezillon
2023-07-25  7:58     ` Boris Brezillon
2023-07-22 23:47 ` [PATCH v14 11/12] drm/shmem-helper: Make drm_gem_shmem_print_info() symbol GPL Dmitry Osipenko
2023-07-22 23:47 ` [PATCH v14 12/12] drm/gem: Add _unlocked postfix to drm_gem_pin/unpin() Dmitry Osipenko
2023-07-25  7:53   ` Boris Brezillon
2023-07-31 13:04     ` Dmitry Osipenko

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=4c5fa735-9bfd-f92a-8deb-888c7368f89e@collabora.com \
    --to=dmitry.osipenko@collabora.com \
    --cc=airlied@gmail.com \
    --cc=boris.brezillon@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emma@anholt.net \
    --cc=gurchetansingh@chromium.org \
    --cc=kernel@collabora.com \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=mwen@igalia.com \
    --cc=olvaffe@gmail.com \
    --cc=steven.price@arm.com \
    --cc=tzimmermann@suse.de \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=yuq825@gmail.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

all inboxes | Powered by JetHome®