Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3572925pxp; Tue, 8 Mar 2022 17:48:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJxIaV2lHsRM9HVno6z7Wf0tbrtxkZU9/crSmt5aN72jWel/MurSiXrXTWpkRXW6sYlBl9AU X-Received: by 2002:a17:902:7896:b0:151:a6fd:dfb3 with SMTP id q22-20020a170902789600b00151a6fddfb3mr20604701pll.124.1646790486908; Tue, 08 Mar 2022 17:48:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646790486; cv=none; d=google.com; s=arc-20160816; b=v0qaVDyP5iR4IEIYF+6BP1e3C/gP7vVpLeZWCDvwypGXWt2z9ymxKkRNnjsCIp70gW P3810c4lftED/vVHzaEQPwwssRXgac/m1pffQpdy2GqZUcpJuZ+wJ3JzO4TjJUyY1KQ3 UsCURsHf5YtJr50VdX7uHquiviy58M8KPoin6r9S7RfU1wnJx0eUXn8Re1uCvRJhZM6w h4eZTDVSeykG5Xj7VmXrU2ZZdL1rYnX0ioiGDz7foSZ/Zh33J6k8bCXx1IJyvYRgfB4i OB/4iZlKhHhvzVLxZVYsmxMnULbssPuWemjjkCNH1IswSkNCn1RkBuYvu6I8HM3/BKdK M/4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=VLNTenH17gTL++hzFtoUTNEHN+pSYqZsQ93MYsewbsE=; b=i0CgqEID+McCJpoIXtjcN/W0psS+Gf3mvFPEyjgdoqb/GggqRNJHTNq96X7RTA4+Kf PFKnS54+rCp1eK3hv06fLfb6X5cS/BOUDaUdMzAAuvgSPD9AwOeAloMoRxbehRx7kkhw E4SMK4poPn3apA7W26fb1a0PNKFB2dHohbrgC2twhQqv//zSL4lzz2SdrIirlrBT1TnN 4Wob/tKoVNSS9dMLibB57Xctu9z/doE//A/W6Agd8M6OE3eqEU69CH9OaALP90U7C6US w2nYdrX9zhJv9npkAJ6K/MGhhz9b6W2H7+Sa80s3fvIoIy5720kuHzKWZZNKwKZjHpD3 BbBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=B+Y+aj0K; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id lt12-20020a17090b354c00b001bd14e030c2si3566750pjb.154.2022.03.08.17.48.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Mar 2022 17:48:06 -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=@gmail.com header.s=20210112 header.b=B+Y+aj0K; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C4A221D06D0; Tue, 8 Mar 2022 16:24:57 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242696AbiCHWYy (ORCPT + 99 others); Tue, 8 Mar 2022 17:24:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34148 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236364AbiCHWYx (ORCPT ); Tue, 8 Mar 2022 17:24:53 -0500 Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EFFE358387 for ; Tue, 8 Mar 2022 14:23:55 -0800 (PST) Received: by mail-wr1-x432.google.com with SMTP id k24so269806wrd.7 for ; Tue, 08 Mar 2022 14:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VLNTenH17gTL++hzFtoUTNEHN+pSYqZsQ93MYsewbsE=; b=B+Y+aj0Kp1KcmHD1TJUXHwyix6ApB1/FqwmXZGhx1wcc4TAOmxh9gxTlBgAGamLqPE vpKcowdhEgZzk2U98r53D5Hy1Scrw6xH8PQcSydekPlZ5HI3qiA9pxOFbKVYi/9OQf1Z 2z+/4YhPKMZ9oKQH20k7HP91wcJX8Isk8gqkO9jES0i3L0GPwD3p1LcGOB9U6h/BRgsQ 8084feHyzqqtSFPTbppFkm13Ecg1wAy6AkYXNngnc+JaHTQVPUGmgGjdIb5GLtIM4Q/G bFqhl4gpP3fujkTcmelxXGFmAibfXsgFjzDNGvuS4OkzK2lYWp6unZQFj+/yXcyvAvNf Zjsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VLNTenH17gTL++hzFtoUTNEHN+pSYqZsQ93MYsewbsE=; b=xQMtrp1FktAexxu3sXQF9sJiSgMt6klYuNQAaKHV1b0FPQRApr7zFywvXedwl1Bh9Y vh+a5s0u9zQywtLN8K6IYpfRSVXk8mdWaRL8saaY95aFSCrQgwLZUoYMukNJf4Cr3gmf K80u5Eqii3vrlu2jmbORtiCntRnWyi0Jmbc1bW65afypB6ezQcR8BsFPOGi4CGpSNYYN YmmWrv5xF2SJaWALOwxw0nLTz1k0RVwyg1s21pZqsQnBO8+EIz0hyjQW9dK7su0A3GWU dm+DUgWZy7bJOTABpZQ5NomHoApwKpKOIrHhHbxJyn3zzbncNHjUyCO8TZ8DPp+k7Mo+ M0Bw== X-Gm-Message-State: AOAM530NbfLzekrmovBwKHlvUbR8dlAWfOo2PpT4pw6b5gxRX7cAa2Wh 2qBqDxWoenw8bZLaHcpZ6PWHtsXAcQm7stXbdOE= X-Received: by 2002:a05:6000:15c5:b0:1f1:e64d:e4c3 with SMTP id y5-20020a05600015c500b001f1e64de4c3mr11545524wry.328.1646778234465; Tue, 08 Mar 2022 14:23:54 -0800 (PST) MIME-Version: 1.0 References: <20220308131725.60607-1-dmitry.osipenko@collabora.com> In-Reply-To: From: Rob Clark Date: Tue, 8 Mar 2022 14:24:22 -0800 Message-ID: Subject: Re: [PATCH v1 0/5] Add memory shrinker to VirtIO-GPU DRM driver To: Dmitry Osipenko 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 Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE 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 Tue, Mar 8, 2022 at 11:28 AM Dmitry Osipenko wrote: > > 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. Hmm, I think we just need the balloon driver to trigger the shrinker in the guest kernel? I suppose a driver like drm/virtio might want to differentiate between host and guest pressure (ie. consider only objects that have host vs guest storage), but even without that, freeing up memory in the guest when host is under memory pressure seems worthwhile. Maybe I'm over-simplifying? > > 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. I think we don't want to do that, because MADV:WILLNEED would be by far the most frequent guest<->host synchronous round trip. So from that perspective tracking madvise state in guest kernel seems quite attractive. If we really can't track madvise state in the guest for dealing with host memory pressure, I think the better option is to introduce MADV:WILLNEED_REPLACE, ie. something to tell the host kernel that the buffer is needed but the previous contents are not (as long as the GPU VA remains the same). With this the host could allocate new pages if needed, and the guest would not need to wait for a reply from host. > > since that isn't using host storage > > s/host/guest ? Yes, sorry, I meant that it is not using guest storage. BR, -R