On 11/4/23 01:55, Gurchetan Singh wrote: > On Sun, Oct 29, 2023 at 4:03 PM Dmitry Osipenko < > dmitry.osipenko@xxxxxxxxxxxxx> wrote: > >> Support generic drm-shmem memory shrinker and add new madvise IOCTL to >> the VirtIO-GPU driver. BO cache manager of Mesa driver will mark BOs as >> "don't need" using the new IOCTL to let shrinker purge the marked BOs on >> OOM, the shrinker will also evict unpurgeable shmem BOs from memory if >> guest supports SWAP file or partition. >> >> Acked-by: Gerd Hoffmann <kraxel@xxxxxxxxxx> >> Signed-off-by: Daniel Almeida <daniel.almeida@xxxxxxxxxxxxx> >> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> >> --- >> drivers/gpu/drm/virtio/virtgpu_drv.h | 13 +++++- >> drivers/gpu/drm/virtio/virtgpu_gem.c | 35 ++++++++++++++ >> drivers/gpu/drm/virtio/virtgpu_ioctl.c | 25 ++++++++++ >> drivers/gpu/drm/virtio/virtgpu_kms.c | 8 ++++ >> drivers/gpu/drm/virtio/virtgpu_object.c | 61 +++++++++++++++++++++++++ >> drivers/gpu/drm/virtio/virtgpu_vq.c | 40 ++++++++++++++++ >> include/uapi/drm/virtgpu_drm.h | 14 ++++++ >> 7 files changed, 195 insertions(+), 1 deletion(-) ... > > Link to open-source userspace? https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15278 I'll add it to the commit message > Also, don't you need a VIRTGPU_PARAM_MADVISE_SUPPORTED or is the plan to > use a DRM version? The ioctl() returns error if DRM_VIRTGPU_MADVISE unsupported, extra flags not needed by userspace > Overall, the series for a generic shrinker seems useful for a wide variety > of DRM drivers, such as Panfrost. > > For virtio-gpu, it could be a tad VIRGIL specific: since other context > types (gfxstream gles, DRM, vk contexts) decrease memory consumption by > either not allocating shadow buffers for textures/buffers, or using blob > memory. > > Maybe we need to design with blob in mind, since we expect virgl to be > deprecated. On Android, it basically is with ANGLE and native contexts. > On Linux, Zink looks good too. Even with memory issues fixed, virgl is > unattractive compared to those solutions. We should finish shmem first since started with it, then move to blobs. My rough idea for the blobs is to use a timer-based approach to avoid frequent virtio syncing with host that will be bad for performance otherwise. Virtio-gpu kernel driver will maintain a list of purgeable blobs and will send the list of idling blobs down to host after a period of inactivity. Virgl may be not interesting for CrOS, but Qemu will continue supporting it. I also expect that today's ARM Chromebooks which use Virgl and only support GL will continue to use Virgl for the next 4 years. > Android specific idea: I wonder if we could tie GEM blob buffers usage to > the lmkd and kill based on that ... ? > > https://source.android.com/docs/core/perf/lmkd > > Is there GEM buffer accounting infrastructure already? Are you talking about killing a guest APP that uses host blobs when host is under pressure? I'm not familiar with how arcvm works, but may assume that it runs a VM per APP. In that case VM is just another process from the lmkd perspective that will be taken down on OOM, i.e. blob buffers already should be seen as a part of a VM's memory by lmkd when they reside in sysmem. -- Best regards, Dmitry
