Received: by 2002:a05:7412:8521:b0:e2:908c:2ebd with SMTP id t33csp1859493rdf; Sun, 5 Nov 2023 18:03:26 -0800 (PST) X-Google-Smtp-Source: AGHT+IFNfKKVb+h2EZqX74d2btune82yGFNnH4tZwV8HsmwBN3tv3ZUj/6DguL3GGK7zkZwtpBvh X-Received: by 2002:a17:903:452:b0:1cc:68a5:f388 with SMTP id iw18-20020a170903045200b001cc68a5f388mr16994952plb.33.1699236205716; Sun, 05 Nov 2023 18:03:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699236205; cv=none; d=google.com; s=arc-20160816; b=nh9K3e37Xenp4zid3LPfzMkw7L5pBowiYJrsGYZccxU+gD9ao/EZss6FMCRHnGRgIm mCgWlSgu1RWaB3mjYEbdBbWqLoVwhfHCLvj1bfzspxWIMt3g/ehkZxYslGFOho3FDrTe o8b45xkX6Fsj/IThrCVC+ubkCwBrswGUK6u8soFoKu95mGVUJk6hiB8jKfwY/7m7eN/z D4+f3Xghmw43S0t9Y97LHawqu/YgohIDk/vBjGP6r8qzja+DFfmI8zeBJDpKqoNQD2oD 8TPEu9bzo4xrNlXmKUjnOtU6sv36NDX7bT/w3ZFQU6Owk2EoH6ySmiqF1Imik22r/1wH DiQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=hV0mCJE4imviY1GNgl+/ne2nSYGEZvt8A0o9WgjSanE=; fh=5WLa8QyBhDKdN4YIA0krtPsIZq3kpNf/yBWZSifQnss=; b=IlwBOc9yhm9lYbgecCMgJcu+T2kG3LBIOQO1+xxQRVdKvrhDKMizEKvGg1IhbaGUab zqNzjby1AkSkzAo3zAPzUhUcjggHUj81rl5BMUw4+pfBzIL8cZu1+diBXV4neZukEjfE TAPR5fjr7a+K/KD4uW6ubQhnDo6N/gNI9YWxrsWBAryZi5LkhRIRWiK3JH+P0qQvO/wT /YExLvhfSCHYC52xxjEbxJghd5Qa9ibVchr3t1fT4/R2mL7htkLEo50b3VnulGV296Yl dHksRyST79UWcaGc5nXIyGwbgARpESfey0cLP88mkUnVeuMuT/fCE/rO9AdAM/jjukNd JUXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=D35ywBv5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id m17-20020a170902db1100b001cc5420241bsi7149636plx.413.2023.11.05.18.03.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Nov 2023 18:03:25 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=D35ywBv5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id F1288805A785; Sun, 5 Nov 2023 18:03:22 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229944AbjKFCDI (ORCPT + 99 others); Sun, 5 Nov 2023 21:03:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229671AbjKFCDH (ORCPT ); Sun, 5 Nov 2023 21:03:07 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 47F93E6 for ; Sun, 5 Nov 2023 18:03:04 -0800 (PST) Received: from [10.3.2.161] (zone.collabora.co.uk [167.235.23.81]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madras.collabora.co.uk (Postfix) with ESMTPSA id 0ACA16607435; Mon, 6 Nov 2023 02:03:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1699236182; bh=xX6wIIpG/Wv5HUsHMt5+qLudM6Mp/o/MT2hir+b8bLg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=D35ywBv5iASzkyh/rZJl4h6aiinrXpqjt3tSFXlRoF3TN1lJpoB/HkYmHve2A7qS4 xHugotys4uc3FBrc76rx1sVTzUuX9elG0F7+tfaOnNgHVjBDkTwfLdTkMXrwj5exOL sFiMUxIKhz6IDlkL8O00CnpIGcJ1BLvtsBe++dugML3fBtRZLEdF/nm9w4mPwni7He MMvF7+JI6uJYeDPkjFA7iPTGw9svnBwB5iHKzxZ33txcn6ggSXt1zUi3wdblNhuYGV dm3LoQTyj/dyEqedBjMrf/Cb8+rdmx4R1PuhRoxByMQB0sjW9jQc7nnLUYxWYo6uDQ ruX7NxfY++rAw== Message-ID: <1228d85a-011b-8b48-61c7-fc760edaf7a1@collabora.com> Date: Mon, 6 Nov 2023 05:02:56 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v18 25/26] drm/virtio: Support shmem shrinking To: Gurchetan Singh Cc: David Airlie , Gerd Hoffmann , Chia-I Wu , Daniel Vetter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , =?UTF-8?Q?Christian_K=c3=b6nig?= , Qiang Yu , Steven Price , Boris Brezillon , Emma Anholt , Melissa Wen , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, kernel@collabora.com, virtualization@lists.linux-foundation.org References: <20231029230205.93277-1-dmitry.osipenko@collabora.com> <20231029230205.93277-26-dmitry.osipenko@collabora.com> Content-Language: en-US From: Dmitry Osipenko In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Sun, 05 Nov 2023 18:03:23 -0800 (PST) On 11/4/23 01:55, Gurchetan Singh wrote: > On Sun, Oct 29, 2023 at 4:03 PM Dmitry Osipenko < > dmitry.osipenko@collabora.com> 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 >> Signed-off-by: Daniel Almeida >> Signed-off-by: Dmitry Osipenko >> --- >> 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