mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Dmitry Osipenko <dmitry.osipenko@collabora.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>
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>
Subject: Re: [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver
Date: Thu, 10 Mar 2022 20:02:22 +0100	[thread overview]
Message-ID: <3caec8f4-1bc8-bd52-4a36-5223b633704e@suse.de> (raw)
In-Reply-To: <c9b344ab-b674-d600-da13-94b329a9d46b@collabora.com>


[-- Attachment #1.1: Type: text/plain, Size: 1382 bytes --]

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.

Best regards
Thomas

> 
>> The patchset adds new helpers for BO purging to struct
>> drm_gem_object_funcs. With this, I think it might be possible to have
>> one global DRM shrinker and let it handle all BOs; independent of each
>> BO's memory manager.
> 
> Thank you, I'll give it a try.

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

  reply	other threads:[~2022-03-10 19:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 ` [PATCH v1 2/5] drm/virtio: Check whether transferred 2D BO is shmem 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 ` [PATCH v1 4/5] drm/virtio: Improve DMA API usage for shmem BOs Dmitry Osipenko
2022-03-08 13:17 ` [PATCH v1 5/5] drm/virtio: Add memory shrinker Dmitry Osipenko
2022-03-08 16:04   ` Dmitry Osipenko
2022-03-09  1:12   ` Rob Clark
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 19:28   ` Dmitry Osipenko
2022-03-08 22:24     ` Rob Clark
2022-03-08 23:36       ` Dmitry Osipenko
2022-03-09  0:56         ` Rob Clark
2022-03-09 20:06           ` Dmitry Osipenko
2022-03-09 21:51             ` Rob Clark
2022-03-09 22:43               ` Dmitry Osipenko
2022-03-14 23:04                 ` Dmitry Osipenko
2022-03-09  8:59 ` Thomas Zimmermann
2022-03-09 11:55   ` Dmitry Osipenko
2022-03-09 19:28     ` Thomas Zimmermann
2022-03-09 22:25       ` Dmitry Osipenko
2022-03-10 19:02         ` Thomas Zimmermann [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=3caec8f4-1bc8-bd52-4a36-5223b633704e@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@linux.ie \
    --cc=daniel.almeida@collabora.com \
    --cc=daniel@ffwll.ch \
    --cc=digetx@gmail.com \
    --cc=dmitry.osipenko@collabora.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=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 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®