From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Rob Clark <robdclark@gmail.com>
Cc: 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>,
Tomeu Vizoso <tomeu.vizoso@collabora.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"open list:VIRTIO GPU DRIVER"
<virtualization@lists.linux-foundation.org>,
Gustavo Padovan <gustavo.padovan@collabora.com>,
dri-devel <dri-devel@lists.freedesktop.org>,
Dmitry Osipenko <digetx@gmail.com>,
Rob Clark <robdclark@chromium.org>
Subject: Re: [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver
Date: Tue, 8 Mar 2022 22:28:01 +0300 [thread overview]
Message-ID: <d2290971-ea22-8203-631e-b896c76a994b@collabora.com> (raw)
In-Reply-To: <CAF6AEGt=aVJ9nR+Wv+bJEFZrn-cNOSNXG1TaJr=Cx-FTgutwKA@mail.gmail.com>
On 3/8/22 19:29, Rob Clark wrote:
> On Tue, Mar 8, 2022 at 5:17 AM Dmitry Osipenko
> <dmitry.osipenko@collabora.com> wrote:
>>
>> Hello,
>>
>> This patchset introduces memory shrinker for the VirtIO-GPU DRM driver.
>> During OOM, the shrinker will release BOs that are marked as "not needed"
>> by userspace using the new madvise IOCTL. The userspace in this case is
>> the Mesa VirGL driver, it will mark the cached BOs as "not needed",
>> allowing kernel driver to release memory of the cached shmem BOs on lowmem
>> situations, preventing OOM kills.
>
> Will host memory pressure already trigger shrinker in guest?
The host memory pressure won't trigger shrinker in guest here. This
series will help only with the memory pressure within the guest using a
usual "virgl context".
Having a host shrinker in a case of "virgl contexts" should be a
difficult problem to solve.
> This is
> something I'm quite interested in for "virtgpu native contexts" (ie.
> native guest driver with new context type sitting on top of virtgpu),
In a case of "native contexts" it should be doable, at least I can't see
any obvious problems. The madvise invocations could be passed to the
host using a new virtio-gpu command by the guest's madvise IOCTL
handler, instead-of/in-addition-to handling madvise in the guest's
kernel, and that's it.
> since that isn't using host storage
s/host/guest ?
next prev parent reply other threads:[~2022-03-08 19:28 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 [this message]
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
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=d2290971-ea22-8203-631e-b896c76a994b@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=robdclark@chromium.org \
--cc=robdclark@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®