From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A01FFC678D4 for ; Thu, 2 Mar 2023 03:26:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 16D8C6B0073; Wed, 1 Mar 2023 22:26:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 11E046B0074; Wed, 1 Mar 2023 22:26:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F28AA6B0075; Wed, 1 Mar 2023 22:26:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id E5E536B0073 for ; Wed, 1 Mar 2023 22:26:58 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B1E79160F29 for ; Thu, 2 Mar 2023 03:26:58 +0000 (UTC) X-FDA: 80522521716.01.636C6C1 Received: from mail-pl1-f179.google.com (mail-pl1-f179.google.com [209.85.214.179]) by imf28.hostedemail.com (Postfix) with ESMTP id DA77BC0003 for ; Thu, 2 Mar 2023 03:26:56 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=I3aW2wiB; spf=pass (imf28.hostedemail.com: domain of rientjes@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677727617; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2g8UviE1kEkFqq9eAKhynAgig45tdIeMwbCgGYlxa20=; b=2/NGxCpxgWjDqW6DbIc3373YCmDAoB+283hj2nfj1Y+evMlNDKXsSzMD3nZYZVrA+Uw+k9 +1tZ+2BiDeN0CO6TjWkexdJPd9yB1BNgbz7fwPULAPzNsOTLRK9RsQqbBArNMw9i/XldFA Itjpi53U6z2A8w7jzkrvn0A5knkSep8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=I3aW2wiB; spf=pass (imf28.hostedemail.com: domain of rientjes@google.com designates 209.85.214.179 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677727617; a=rsa-sha256; cv=none; b=Tej5UR9Yq5XYb+mN69hTzrDVo2q78SBhYeGdAgPH96rJRF/gl6OpTU/DMjGHqnkECqNWwH 9uzrW84qhHCDqTkWQ+A/VGJ+QSQLREQ7dmI04B0fvlPEb8BKTE48MTHhwms3HNcOsYUx4w AMiFToiMZDc3BR2dN0zBpjI4yrEa070= Received: by mail-pl1-f179.google.com with SMTP id a2so5768294plm.4 for ; Wed, 01 Mar 2023 19:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=2g8UviE1kEkFqq9eAKhynAgig45tdIeMwbCgGYlxa20=; b=I3aW2wiBG01Yzon1TKAIHv9x2nch3BVxByOC6NaL6FQgs3kL1V7QXsKoFMqCL9ia1x Gv9OwqnIubVb9HvyqfPYa3wU2LEbj0omk/TEOHySWA0jS0cir/0d5cYVY2HicG4UbzbQ hi0mo7RiHv/YToly6/xnN/OjKSl7IZz6etQVPj/bVMCCSy8Vco1gXwEZpxYFvjpvypwQ HTylwqi3hTSPlvX7fVcPr72xmurulp9PKyXD22Y5u8B0O+X90uqRUyhwvoKwqHfknQvG TzT6CFWd9ADVvDhew+6/V4HHYOHd7d2ZCvYpLCUxUFzCW/+GFj5+YPXDkfaY+V2LlLqS 7X+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2g8UviE1kEkFqq9eAKhynAgig45tdIeMwbCgGYlxa20=; b=ZEvP4UkwP9DDm75ha13te6IPyuMkkO436h0Tb9F8NnWCqP89h2Kix5WYRdPVG5Hi7T Jr9jYe31sQ4MZ7X1zUaREJZcVDGvs5J3kTyYHTxF5wGGQMnVLR1kG8yU9UtxDkS8Qj0m 3mD+Yv/wMovmA73U2aIUrkal0Hb7s+lOwxJQmGUeBVL+cp4TcYaEaINnUfgO65rZnPTG M7IWWTwJcHJuhtCmidx6jdnuEQWIDMshvQaghfDWaqemHgZByeNkRAur8ZQD1tLB0MoW SOQqGE7f29wmCc0C0bRUDt5PdQJr/4I0fBJceTb1OLrcoY4LF+KP+/qNUirf+w1GzDbc XXDQ== X-Gm-Message-State: AO0yUKW42lzmCVR8MM8tgHrL+djCd8CONCL5N5EwamgpXAcHv+fDl1nZ cimGBk0981aDk6aXzrd2aCihrQ== X-Google-Smtp-Source: AK7set+mFSclLWu5PamoIAn7F8ypQviYjDCGxIJe7RbJwAAUC/ngPIfBegjRkstrSzQWQPbExb+n6w== X-Received: by 2002:a17:903:704:b0:19a:5a9d:3c with SMTP id kk4-20020a170903070400b0019a5a9d003cmr79895plb.16.1677727615410; Wed, 01 Mar 2023 19:26:55 -0800 (PST) Received: from [2620:15c:29:203:5530:853:8d92:ba58] ([2620:15c:29:203:5530:853:8d92:ba58]) by smtp.gmail.com with ESMTPSA id x26-20020aa784da000000b005a8f1187112sm8569832pfn.58.2023.03.01.19.26.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Mar 2023 19:26:54 -0800 (PST) Date: Wed, 1 Mar 2023 19:26:53 -0800 (PST) From: David Rientjes To: David Hildenbrand cc: SeongJae Park , "T.J. Alumbaugh" , lsf-pc@lists.linux-foundation.org, "Sudarshan Rajagopalan (QUIC)" , hch@lst.de, kai.huang@intel.com, jon@nutanix.com, Yuanchu Xie , linux-mm , damon@lists.linux.dev Subject: Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit In-Reply-To: <5751ca20-9848-af42-bd1d-c7671b5796db@redhat.com> Message-ID: References: <20230228223859.114846-1-sj@kernel.org> <5751ca20-9848-af42-bd1d-c7671b5796db@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DA77BC0003 X-Stat-Signature: qzt7hbrxkmjy9afa67byt8hz35e9ot6n X-Rspam-User: X-HE-Tag: 1677727616-307101 X-HE-Meta: U2FsdGVkX1+9Yk9Q1koCnBd9P/3Q4WuZ1EbcfZ7IK/6NCjCwQT7+i9utPdgeESVkw0jspbMaHmj1kOM8T/BdaNBFVI7zSjPVkLHovHPFXijr9+WIRRm8vKf/NNwdvxcAzGO99j1sY/qB5U6RotZ05jaqB9PJGx0Dn0CLk9rHy/97WlfuWt7J5krnu9vcr5Lrr3HzjbhDGJkvRAQG+gTbhhaWAJNTKspSkgYsvgPgXnNgbCOa5QtLAEytNSHPpw3tr5YUScY+r9JVZWcOpvo1KiSdWIi+YqMJYqKn3zwwsgJpA2X5CHJmiEwQbSjVir950URF3nHxYqXwsAxj8qo8atrQqIdCw31RNmR3MtdhMsWCUKDX2HQQwbwS6dT9bVKctoyysTJjZGW0HPx4WqOy9QDCbfUtB9mC3J8cENXjsrpocllkDeIWyMax0RE3rMgGN07wywZaxVY+jQMPMcBkh2+vrIY59ObJXB0A8qGCUS5uSwWmpvShIlM2m8epjdmxDqRdvR+buRzKpGp8/HgMhAWMp0Vk8dyJXbmgZSfVTPEGykWdTTKST/FBw0rB8PTa5+OfsIqkD6aUcgEojlgTsM2/4wsL1X7N4eJR6+GPz0AKjyrL2vVOvjtswCg+tq5YpGhWjGcxJqQWXSESOonID5hmp6TSIy3+LAXvdzZPwNUiuUShU8qjZuiIdnz5//jvt9tbhEKRlecRx3kB+QBg5DtRl9MUbl4TE/vexNd+SjKKO46QL4w54tX0vhipLboVHZULGiWX9qytDfxBHKXdLCqgKhdyLRKRGnyskfXuNrRtv/CdWy050SJU4AuqpFbcMr2GbLB6MiEGtRL/KzNR/hfBqil/u0Or7SpTwZpWV1ArOizK+/UiX52rSBwEsRuZoMqMv68HnTSUrtY+XoR/cgePA5QYKBDKWUTeRh1fxllBBI5ikpSaeJjhJw0lmqVoT8SntDWo54JuiaJnnDM wrbznFNy aNksKodcQeCh75/GhQm+T8pm5gXNsECgyA97aXafwq3f9WOD8Jllx8ERkpymRtcvcbu5iRiPuSuYjAkQYqjOnEqdhrd8fs29JNd5ES1nYE0VElCYwh24UvTxcrQ8l6LKzAtLakIkDS0TKgseGgB0f0Cg+oFz8ws16t2aT9BU0DwhEOdKF/NU1KxuNpp6XhrAfHrj8smI+JFNmsTOmBikKnbe8fVH5FKygokPXplJsFLf3NmhAArMACRoQiwSUGaQt0nJmzbRFGJRPXag9rr+CUiV4YIx0UXWATUSbwBi0Iu3vJ6whvxAylwBaFYoKiOnjJLSfVKBtd8PXIZAp29HYKDu79inWRax/7wRExPcFvNhPuM3jgoEQB3wf1w6uDI0vfIT+I8x6312zMS0= X-Bogosity: Ham, tests=bogofilter, spamicity=0.008101, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 28 Feb 2023, David Hildenbrand wrote: > On 28.02.23 23:38, SeongJae Park wrote: > > On Tue, 28 Feb 2023 10:20:57 +0100 David Hildenbrand > > wrote: > > > > > On 23.02.23 00:59, T.J. Alumbaugh wrote: > > > > Hi, > > > > > > > > This topic proposal would be to present and discuss multiple MM > > > > features to improve host memory overcommit while running VMs. There > > > > are two general cases: > > > > > > > > 1. The host and its guests operate independently, > > > > > > > > 2. The host and its guests cooperate by techniques like ballooning. > > > > > > > > In the first case, we would discuss some new techniques, e.g., fast > > > > access bit harvesting in the KVM MMU, and some difficulties, e.g., > > > > double zswapping. > > > > > > > > In the second case, we would like to discuss a novel working set size > > > > (WSS) notifier framework and some improvements to the ballooning > > > > policy. The WSS notifier, when available, can report WSS to its > > > > listeners. VM Memory Overcommit is one of its use cases: the > > > > virtio-balloon driver can register for WSS notifications and relay WSS > > > > to the host. The host can leverage the WSS notifications and improve > > > > the ballooning policy. > > > > > > > > This topic would be of interest to a wide range of audience, e.g., > > > > phones, laptops and servers. > > > > Co-presented with Yuanchu Xie. > > > > > > In general, having the WSS available to the hypervisor might be > > > beneficial. I recall, that there was an idea to leverage MGLRU and to > > > communicate MGLRU statistics to the hypervisor, such that the hypervisor > > > can make decisions using these statistics. > > > > > > But note that I don't think that the future will be traditional memory > > > balloon inflation/deflation. I think it might be useful in related > > > context, though. > > > > > > What we actually might want is a way to tell the OS ruining inside the > > > VM to "please try not using more than XXX MiB of physical memory" but > > > treat it as a soft limit. So in case we mess up, or there is a sudden > > > peak in memory consumption due to a workload, we won't harm the guest > > > OS/workload, and don't have to act immediately to avoid trouble. One can > > > think of it like an evolution of memory ballooning: instead of creating > > > artificial memory pressure by inflating the balloon that is fairly event > > > driven and requires explicit memory deflation, we teach the OS to do it > > > natively and pair it with free page reporting. > > > > > > All free physical memory inside the VM can be reported using free page > > > reporting to the hypervisor, and the OS will try sticking to the > > > requested "logical" VM size, unless there is real demand for more memory. > > > > I think use of DAMON_RECLAIM[1] inside VM together with free pages reporting > > could be an option. Some users tried that in a manual way and reported some > > positive results. I'm trying to find a good way to provide some control of > > the > > in-VM DAMON_RECLAIM utilization to hypervisor. > > > > I think we might want to go one step further and not only reclaim > (pro)actively, but also limit e.g., the growth of caches, such as the > pagecache, to make them also aware of a soft-limit. Having that said, I still > have to learn more about DAMON reclaim :) > I'm curious, is this limitation possible to impose with memcg today or are specifically looking to provide a cap on page cache, dentries, inodes, etc, without specifically requiring memcg?