Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3514470pxp; Tue, 8 Mar 2022 16:21:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJwDggd/oxqyQhK2kH4afF7ockIeoYUxeTkxCCmrZcdJ7JKJM0/ZxubRrAkB6FhEPlFiOtZ3 X-Received: by 2002:a17:902:f549:b0:151:f9ce:4ec1 with SMTP id h9-20020a170902f54900b00151f9ce4ec1mr7926898plf.3.1646785309477; Tue, 08 Mar 2022 16:21:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646785309; cv=none; d=google.com; s=arc-20160816; b=qTrD3bgN4j8CwwkVRkXy4R0DVqaQZtm1MnWOkSr8n3Gdpqtp2gra9Jjsp2JDdamqLD TjYuxwT4TMGLsu0p2k4CjZoIxbz3H+bNtjW5A3ZXMj7xV3rdcsNYGEw91SiGmyfZc6H4 mtp3FdJtWo3xAMUSiTuxp5sBt0qFSfKUtAZvg3VXX2+Ny7IDFlRx+vpC6HX8OjprPsCn 685GPtcycpoLBHjH55dF85UIUi2SKzieh8FsbTXRrPJnMrhNgudBUjdUH45m4a9oNnCb K9yBfJ7/6FWLK8lmScHsvKlY0d875xcJO7JCXOa/yUVsoHLjalEdl60h4PPp1Fk5QNWL h0Ig== 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 :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=2r6yfDzXXe1ZBf/2cg8OCCZxjAwo4lqYWdTvPYXgirU=; b=SqbFyPw3uTnApEKWxs7NG8CZhJaYzVV7noIYR27+KI5YIqi9CsviDD7sgk9UxUJDDQ 1q+S2lsqAnh8ZQGPYpzdx3CZpXOXaY8K/wAMo1vpIbm2PeP2gT+Kev6qiDYzzxduhHgt aqxQhvmj0RN/8DnCn9iGnAScRuUrtHceS2+UeWlgJeO+O91jCWMDEKCrQCGx0UQiajP2 Ra4ieiUA/uFyfJcXFIKZJ8vuCSghWLdpSSatZ6gjNAtKricfU3ONUUwh0ZvrTvV5DsPA gMI0es6cfFzZn3W0tp6wnXNielQa91+OYGc7R3Y5sq9fyhtbK7wv4ddoJ2q7Sn5HdBXO W4kA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=JaIccFmi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id n75-20020a628f4e000000b004e1dc67eaa8si287451pfd.306.2022.03.08.16.21.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 16:21:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=JaIccFmi; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 77FF0102409; Tue, 8 Mar 2022 15:46:05 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349446AbiCHT3I (ORCPT + 99 others); Tue, 8 Mar 2022 14:29:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34206 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349129AbiCHT3F (ORCPT ); Tue, 8 Mar 2022 14:29:05 -0500 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [46.235.227.227]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 64C832FFFF for ; Tue, 8 Mar 2022 11:28:07 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: dmitry.osipenko) with ESMTPSA id 8E2181F444B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1646767685; bh=wTrQZzTeDzl3S/Woe+temKvCkXTTxdkP03ZFoe6Rj9E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=JaIccFmi1jX1ewpbOHkkQGyiOhdvqKxkBql/3KQWmeEBQn/mP+wHpnZhb1wis3XJI XZhjoIwXc65vjwfJ/RWJzRoRjZQ17T4hYNBj1rk3qnMxIBzU2jmPIgD53sRpDbTvCA L5xqICzA0o8+u8NbxpCDnGKpDaGP08JoVK46goArxgFJElNE/jkMtCa15MfDt/YGzi LYURN3gjJ0/HMiCflPowekOpYyKzx0v55sCPVNEipd7jXFkRabu2pEmsAeOc8J+/+p EV4yRSp29+JTPdXCnN+2MrvPyFySxaO9NBklmjUqlJftdKQ6RDxPu8nNXlPWuZh1+k 0ZqbjSNLJScNg== Message-ID: Date: Tue, 8 Mar 2022 22:28:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver Content-Language: en-US To: Rob Clark Cc: David Airlie , Gerd Hoffmann , Gurchetan Singh , Chia-I Wu , Daniel Vetter , Daniel Almeida , Gert Wollny , Tomeu Vizoso , Linux Kernel Mailing List , "open list:VIRTIO GPU DRIVER" , Gustavo Padovan , dri-devel , Dmitry Osipenko , Rob Clark References: <20220308131725.60607-1-dmitry.osipenko@collabora.com> From: Dmitry Osipenko In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/8/22 19:29, Rob Clark wrote: > On Tue, Mar 8, 2022 at 5:17 AM Dmitry Osipenko > 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 ?