All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org,
	Gustavo Padovan <gustavo.padovan@collabora.com>,
	dri-devel@lists.freedesktop.org,
	Dmitry Osipenko <digetx@gmail.com>,
	David Airlie <airlied@linux.ie>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Gurchetan Singh <gurchetansingh@chromium.org>,
	Chia-I Wu <olvaffe@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Daniel Almeida <daniel.almeida@collabora.com>,
	Gert Wollny <gert.wollny@collabora.com>
Subject: Re: [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver
Date: Fri, 11 Mar 2022 00:32:37 +0300	[thread overview]
Message-ID: <ef372381-2a80-bb2f-c999-bb55c5596475@collabora.com> (raw)
In-Reply-To: <3caec8f4-1bc8-bd52-4a36-5223b633704e@suse.de>

On 3/10/22 22:02, Thomas Zimmermann wrote:
> Hi
> 
> Am 09.03.22 um 23:25 schrieb Dmitry Osipenko:
>>>
>>> The reason for this work is to keep GEM shmem pages mapped and allocated
>>> even while the BO is neither mapped nor pinned.  As it is now, GEM SHMEM
>>> creates and releases pages on each pin and unpin, and maps and unmaps
>>> memory ranges on each vmap and vunmap.  It's all wasteful. Only the
>>> first pin and vmap calls should establish pages and mappings and only
>>> the purge and free functions should release them.
>>
>> Hm, aren't maps and pins already refcounted?
> 
> They are. But even when the refcounter reaches 0 on deref, there's no
> need to remove the mapping or free the memory pages. We can keep them
> around for the next ref operation.  Only the shrinker's purge or freeing
> the object has to do such clean-up operations.  Such behavior is
> supported by TTM and we already use it in VRAM helpers as well.

When driver won't want to pin BO at the creation time? Looks like all
shmem users do this today, and thus, pages shouldn't be freed until BO
is destroyed or purged.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Almeida <daniel.almeida@collabora.com>,
	Gert Wollny <gert.wollny@collabora.com>,
	Tomeu Vizoso <tomeu.vizoso@collabora.com>,
	David Airlie <airlied@linux.ie>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	virtualization@lists.linux-foundation.org,
	Gustavo Padovan <gustavo.padovan@collabora.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Dmitry Osipenko <digetx@gmail.com>,
	Gurchetan Singh <gurchetansingh@chromium.org>
Subject: Re: [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver
Date: Fri, 11 Mar 2022 00:32:37 +0300	[thread overview]
Message-ID: <ef372381-2a80-bb2f-c999-bb55c5596475@collabora.com> (raw)
In-Reply-To: <3caec8f4-1bc8-bd52-4a36-5223b633704e@suse.de>

On 3/10/22 22:02, Thomas Zimmermann wrote:
> Hi
> 
> Am 09.03.22 um 23:25 schrieb Dmitry Osipenko:
>>>
>>> The reason for this work is to keep GEM shmem pages mapped and allocated
>>> even while the BO is neither mapped nor pinned.  As it is now, GEM SHMEM
>>> creates and releases pages on each pin and unpin, and maps and unmaps
>>> memory ranges on each vmap and vunmap.  It's all wasteful. Only the
>>> first pin and vmap calls should establish pages and mappings and only
>>> the purge and free functions should release them.
>>
>> Hm, aren't maps and pins already refcounted?
> 
> They are. But even when the refcounter reaches 0 on deref, there's no
> need to remove the mapping or free the memory pages. We can keep them
> around for the next ref operation.  Only the shrinker's purge or freeing
> the object has to do such clean-up operations.  Such behavior is
> supported by TTM and we already use it in VRAM helpers as well.

When driver won't want to pin BO at the creation time? Looks like all
shmem users do this today, and thus, pages shouldn't be freed until BO
is destroyed or purged.

  reply	other threads:[~2022-03-10 21:32 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 13:17 [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver Dmitry Osipenko
2022-03-08 13:17 ` Dmitry Osipenko
2022-03-08 13:17 ` [PATCH v1 1/5] drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling Dmitry Osipenko
2022-03-08 13:17   ` Dmitry Osipenko
2022-03-08 13:17 ` [PATCH v1 2/5] drm/virtio: Check whether transferred 2D BO is shmem Dmitry Osipenko
2022-03-08 13:17   ` Dmitry Osipenko
2022-03-08 13:17 ` [PATCH v1 3/5] drm/virtio: Unlock GEM reservations in error code path Dmitry Osipenko
2022-03-08 13:17   ` Dmitry Osipenko
2022-03-08 13:17 ` [PATCH v1 4/5] drm/virtio: Improve DMA API usage for shmem BOs Dmitry Osipenko
2022-03-08 13:17   ` Dmitry Osipenko
2022-03-08 13:17 ` [PATCH v1 5/5] drm/virtio: Add memory shrinker Dmitry Osipenko
2022-03-08 13:17   ` Dmitry Osipenko
2022-03-08 16:04   ` Dmitry Osipenko
2022-03-08 16:04     ` Dmitry Osipenko
2022-03-09  1:12   ` Rob Clark
2022-03-09  1:12     ` Rob Clark
2022-03-09  1:12     ` Rob Clark
2022-03-09 11:55     ` Dmitry Osipenko
2022-03-09 11:55       ` Dmitry Osipenko
2022-03-08 16:29 ` [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver Rob Clark
2022-03-08 16:29   ` Rob Clark
2022-03-08 16:29   ` Rob Clark
2022-03-08 19:28   ` Dmitry Osipenko
2022-03-08 19:28     ` Dmitry Osipenko
2022-03-08 22:24     ` Rob Clark
2022-03-08 22:24       ` Rob Clark
2022-03-08 22:24       ` Rob Clark
2022-03-08 23:36       ` Dmitry Osipenko
2022-03-08 23:36         ` Dmitry Osipenko
2022-03-09  0:56         ` Rob Clark
2022-03-09  0:56           ` Rob Clark
2022-03-09  0:56           ` Rob Clark
2022-03-09 20:06           ` Dmitry Osipenko
2022-03-09 20:06             ` Dmitry Osipenko
2022-03-09 21:51             ` Rob Clark
2022-03-09 21:51               ` Rob Clark
2022-03-09 21:51               ` Rob Clark
2022-03-09 22:43               ` Dmitry Osipenko
2022-03-09 22:43                 ` Dmitry Osipenko
2022-03-14 23:04                 ` Dmitry Osipenko
2022-03-14 23:04                   ` Dmitry Osipenko
2022-03-09  8:59 ` Thomas Zimmermann
2022-03-09  8:59   ` Thomas Zimmermann
2022-03-09  8:59   ` Thomas Zimmermann
2022-03-09 11:55   ` Dmitry Osipenko
2022-03-09 11:55     ` Dmitry Osipenko
2022-03-09 19:28     ` Thomas Zimmermann
2022-03-09 19:28       ` Thomas Zimmermann
2022-03-09 19:28       ` Thomas Zimmermann
2022-03-09 22:25       ` Dmitry Osipenko
2022-03-09 22:25         ` Dmitry Osipenko
2022-03-10 19:02         ` Thomas Zimmermann
2022-03-10 19:02           ` Thomas Zimmermann
2022-03-10 19:02           ` Thomas Zimmermann
2022-03-10 21:32           ` Dmitry Osipenko [this message]
2022-03-10 21:32             ` 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=ef372381-2a80-bb2f-c999-bb55c5596475@collabora.com \
    --to=dmitry.osipenko@collabora.com \
    --cc=airlied@linux.ie \
    --cc=daniel.almeida@collabora.com \
    --cc=daniel@ffwll.ch \
    --cc=digetx@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gert.wollny@collabora.com \
    --cc=gurchetansingh@chromium.org \
    --cc=gustavo.padovan@collabora.com \
    --cc=kraxel@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olvaffe@gmail.com \
    --cc=tomeu.vizoso@collabora.com \
    --cc=tzimmermann@suse.de \
    --cc=virtualization@lists.linux-foundation.org \
    /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.