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 9E2E9C64EC7 for ; Tue, 28 Feb 2023 09:21:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EF1636B0071; Tue, 28 Feb 2023 04:21:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E7B426B0072; Tue, 28 Feb 2023 04:21:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF4CC6B0073; Tue, 28 Feb 2023 04:21:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B91E26B0071 for ; Tue, 28 Feb 2023 04:21:04 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7D861A11F2 for ; Tue, 28 Feb 2023 09:21:04 +0000 (UTC) X-FDA: 80516156448.16.942146F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id 172D640006 for ; Tue, 28 Feb 2023 09:21:01 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=iMZQhvLM; spf=pass (imf04.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677576062; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eP2B9wy6LkH7DG8a7zF0uJPE1bICofbLjebMJuzvhcE=; b=IUrJc6Nejf5kIq7NWaRDyv44Kv3au4pqXL5jbxhuo/COZye0Uq+I5x+yyQ9NTGb1nN1GUB AdSM1ZZKoqROrtdSPj4tZHdRghqIvFgTLZl+XRbl3NJiyD3+/owWX/wgHbtiFF9Nzlwojz j0eyfcO8MVeWqv0PyyUg0W0AGlkqjmM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=iMZQhvLM; spf=pass (imf04.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677576062; a=rsa-sha256; cv=none; b=eCCOrpe6Ndr+zpor1FPw9X90G7incGYLfQAzxLZ5va1MvLUGH4lnUMew5jIH9A4QLhKbng 443F7DGgyYea7bDI1A7wZYR2XAc8bUg0C1CvjlJbPkHxlVnL00wpz1dROVoISvT2VnqLEV 8LChfwI0rIJy15fGPkm0QFZOGexndqs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677576061; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eP2B9wy6LkH7DG8a7zF0uJPE1bICofbLjebMJuzvhcE=; b=iMZQhvLMh7jZ0F3lCxwWDwHj8c9iBlyJT0lVfpQboXETd0KkdjmBK/Cl0sI+oA8J/paI7k 5/gfa6vC4gB94QSwULt4bd5Iy0kTftN7FBJMbqhLALAIbBYBFfJlXyAOY+k18J/CsvE7kl U2Hq4QL6g/WHZptSRrWDlYim9LizXts= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-668-BFhV4vKEOeOKguf8_wr-hg-1; Tue, 28 Feb 2023 04:21:00 -0500 X-MC-Unique: BFhV4vKEOeOKguf8_wr-hg-1 Received: by mail-wm1-f70.google.com with SMTP id az12-20020a05600c600c00b003e8910ec2fdso3391308wmb.6 for ; Tue, 28 Feb 2023 01:21:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eP2B9wy6LkH7DG8a7zF0uJPE1bICofbLjebMJuzvhcE=; b=Qx5hY832Pkx7RpBj0+J6teWrGwF6Gpn1qWqU/PxAltY8w6Bc6XCVDCxSLHRUAyhkDC HEoQJPgG+NLwtU5lWqgexkV4qeqwu2B7p3ypR4QtUrNu+UFa39KypaGQa7kicHH2Xtlx ncEgDCxlxcXmSVRGqJrlw2Gm6kVTA/qbRlluepWfJlG8GJOQJnpcATH9fg2lwqg58Cni t7q0xPSjxI/+qnc7t4t0hRZihxPRU88N0ZDAJ7dJ01ITBjFt+uRAykdGV0DPE/SeSWLH 7EfdTyo2VMWR9Zaoso0hdSCQZj2+rVOZbQ9g/2A8N4PwD5JXvogZtbGr3ILJAQo37Fm2 xFrA== X-Gm-Message-State: AO0yUKXKkISq7EVdwCGEATJvCON5wi6gAJrt3qbrvf4FiNT7qbxjfbJz dSvt3AmczBOeG4rLOVOccxmoEI9Vrauwf/3L1pY8netldvCTJAyN4kIRDMJ6rEHAzL0cqQ8om4T lGnNQ2JTj1Uc= X-Received: by 2002:a05:600c:18a2:b0:3eb:4162:7352 with SMTP id x34-20020a05600c18a200b003eb41627352mr1780885wmp.23.1677576059159; Tue, 28 Feb 2023 01:20:59 -0800 (PST) X-Google-Smtp-Source: AK7set8akS+KKnv5hUG/o1aI135pSzByYgKgVr9x5ZcRGErlQ/P9EYs/JGgJABy2Cy5EZ+bJSVF4BA== X-Received: by 2002:a05:600c:18a2:b0:3eb:4162:7352 with SMTP id x34-20020a05600c18a200b003eb41627352mr1780865wmp.23.1677576058781; Tue, 28 Feb 2023 01:20:58 -0800 (PST) Received: from ?IPV6:2003:cb:c706:b800:3757:baed:f95e:20ac? (p200300cbc706b8003757baedf95e20ac.dip0.t-ipconnect.de. [2003:cb:c706:b800:3757:baed:f95e:20ac]) by smtp.gmail.com with ESMTPSA id p15-20020a7bcdef000000b003e200d3b2d1sm11821413wmj.38.2023.02.28.01.20.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Feb 2023 01:20:58 -0800 (PST) Message-ID: Date: Tue, 28 Feb 2023 10:20:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 To: "T.J. Alumbaugh" , lsf-pc@lists.linux-foundation.org Cc: "Sudarshan Rajagopalan (QUIC)" , hch@lst.de, kai.huang@intel.com, jon@nutanix.com, Yuanchu Xie , linux-mm References: From: David Hildenbrand Organization: Red Hat Subject: Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: 1f4impe4psxfttjnkr77r4bto9e76f7r X-Rspamd-Queue-Id: 172D640006 X-HE-Tag: 1677576061-715020 X-HE-Meta: U2FsdGVkX18AByjGRcEBd5iT4GpX4kwmNHY4q58Fc7LHQEZLmfn8SUZoauRbmKcI6/pgXdrIyk4GdbcvTiPp2GXoEpTPgz64NfFVXXOY5I58iov7DiegVp0kttQkwSnCCF0SMwYKhNxNipUG4QdrPan+FUrIhJU0dxbaWnVaJtYX8pXqB/Pi9dpLNr+Al/qQ4u/8uDGMPQrUFaX1CCiiNxyh0JW6eeQd3l7nXx662LMpvMq+0fstjY51ez4TQp4yziWKKc6aG8tVrtxi4YGeLeDR5SWy2OsDkkcDSHppKlv1FgiFZMMI7UtqGlrzo7ki7TaBeMfYt1Zv4VPN1v/eyNCuGxDhWYJT0R98BAwUKLBBwOS6V59oHw+jg4YPzy2nzdlto6o3CnAJFaTmWdqiosg/ff2RqGtHg2MFQrYFklaQNhODtWPhednyl0Igr77nduj8XP53VNSCcMn0Xk86Ei2U644l8WIhXyplo3KFeVOEp4hCB96XGfnZcF9unvCQTkiOmAak0yyI1PSkyhWI/oCjgz9hDAX87X60Z3NnPXpoMqzDJJ6rAU5n7zY4t8+ojMo5FkWz+7qyQjukDCyrDMlbRjygb0jLTaU1xHT87LgN0Oeriy87I6fPNrC2kN1Wf9rU+mOU79IWunw3F6JYO32WQFQlkOh1ub0GnYtdpCTIODMxE0gy41ttgGLVYilusiDSpShtZ+JIDYsO6rAibZLo9zO+9RQ8MEaeWDKBh017DGxgfHs1pWdySv/KywHEEsMvT584sJbTK2rvilR3LD9QKHO0cCQ4H8gQS7tEEUfU3w9INzdbwjeGNwLWKc3r0PxUbDc7+gmfg2jjthN2j2Iy+/l2V653jcDYTtuTAS4fFvdeyrmX08KD/NqkcwbdXlCxpO2P7YAEzjlLoMlGv6r70HkLziohtaD6/Izp8oamhZ2RD7MnH7bnLBG5RrEzC3piCHbtr6Ljblzj84g Zm78KE+e 34YRsFCwWDtdCuyPttaRdB7a2Mg501qmRH1uY438Zl3m4ow5RJeszt8a82rlCKmL2gY8lD+Eix75mKj+GgGJ5PoRGLVc/xNTsDn2zgDRcAfg0X+HYExGVVdQD0v3xuej+NmlV7+uCYYVFJrzzsCVEz9XxNucEqY0U/IPFe7PT9WCYD04julZqVo72UlhnN9bKiZi7O/j9fP+ruMQNmg4T7IhX7WnrnyVvy9+7vOfkCSlievHD8NNZOkTjmi9uOAfy1n/l66GSW73mg62h89ly29mpu9x9xoc7kV1N+pN4pQWJiOo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. -- Thanks, David / dhildenb