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 30F1AC64EC7 for ; Tue, 28 Feb 2023 22:52:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 984926B0074; Tue, 28 Feb 2023 17:52:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 90D7F6B0075; Tue, 28 Feb 2023 17:52:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 787946B0078; Tue, 28 Feb 2023 17:52:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 6663D6B0074 for ; Tue, 28 Feb 2023 17:52:51 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2DCF1140C96 for ; Tue, 28 Feb 2023 22:52:51 +0000 (UTC) X-FDA: 80518202142.13.274E231 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id C5128180006 for ; Tue, 28 Feb 2023 22:52:48 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IR275j0V; spf=pass (imf24.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1677624769; 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=KSkx1WZQdN5DNH0qm7hxBqFACCwZTS1b5AtHMrLmxf8=; b=d+PQdlwkPvJwzFMqhm3bFx2V35ZJWtyIFzZhoivrQPhJRWlJx+6vSkCUB5jDNun1ceGfqF jM+Y4jwv+DMV3XMkIwfPcaeBXhlZ/nvENzrrETXkzr+IGplQx3WhegUkBa6yR9QbIDHMoR l+LWmNu0N1MDk1vXb1YiXZUWvVyTQj4= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=IR275j0V; spf=pass (imf24.hostedemail.com: domain of david@redhat.com designates 170.10.129.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=1677624769; a=rsa-sha256; cv=none; b=NaPws6Cxn2TMvXzElG6ygqhTiW7H2guSxlUI3HMVMQll+Y2izcFETc0eMNp0ADhLiGwulD joqIfqWzHoeht6FPa4rxAewW/UExKwD36IqSPrjeTwuvBPXysTIZfVI6Bv+Sd/6QUnkjGt CvbiKff1yuwVkJ7srd1L/JcvRsEoC6k= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677624768; 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=KSkx1WZQdN5DNH0qm7hxBqFACCwZTS1b5AtHMrLmxf8=; b=IR275j0VHmBzpyG35mOhI3zXvqlrJGxSu3nNOHQesj0eHasSBmwIQr1aB0T1nTq4UXmM/C oobThdraWdWDXoKgxpIeBB9M1a28L5wz+BmSdF2vc/mFUTPnQuzkWEIi7eXQFApd+p60if yDL+5HKXLpmtfLC6N+oXZHAXsmk9nTw= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-447-C9C0B6QROFGgXEXsatglFw-1; Tue, 28 Feb 2023 17:52:44 -0500 X-MC-Unique: C9C0B6QROFGgXEXsatglFw-1 Received: by mail-wm1-f71.google.com with SMTP id j6-20020a05600c1c0600b003eaf882cb85so4788621wms.9 for ; Tue, 28 Feb 2023 14:52:44 -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:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KSkx1WZQdN5DNH0qm7hxBqFACCwZTS1b5AtHMrLmxf8=; b=ke1ZJECPJIMllsMAkuSUoJ5zGeQFIEY3JRZV5uRvKFaEzh/cVRr5+lgrZIHZNWA7nS Q26yQnYgWVZUxjZaOdKmfJG7o/NAgti2C8QVt9HxSjKtkH1PdGKAOnlY0EtdYfWedO+D QWbmXTb1jAm/vNlcFavwGXa17Qpr5Rf552YSTZLBmn8u7c74AkupA5yRSRJSZMu36NZk lhMBnVBELN30y54nWHilP+kCV8CD1EgyZ7nQy/2YoDxpEQPV1NFbNJncSkE5sBoRAXVb D/XeaFHkUsxFJLZV5e7ia8QBJOjWL5X25otvmbf7x4zYHsFHoQDQq+vrsq/4ygKd3o92 CX7w== X-Gm-Message-State: AO0yUKVtcIFxDDWHFbllJ9/vxAX0vC5ynRK3ailVkHE41OM/FEPf5c8N Gb5XPYC5BJ4c/yBd76C/NFd8NbOcYGuhXuesHqsJwd72H25VZNoj7dfLI0rf7lACcXQX65ZYNuH QcC2L8IlCOOk= X-Received: by 2002:a5d:59a9:0:b0:2c3:d032:5b29 with SMTP id p9-20020a5d59a9000000b002c3d0325b29mr3312284wrr.12.1677624763703; Tue, 28 Feb 2023 14:52:43 -0800 (PST) X-Google-Smtp-Source: AK7set/tbtOOZ+0X8Q0TBm5m1WMfIB2tqHCEDxn7HRIEwj8y/XYzo/A2WddmJERMPSL6s+bxkUZ/hQ== X-Received: by 2002:a5d:59a9:0:b0:2c3:d032:5b29 with SMTP id p9-20020a5d59a9000000b002c3d0325b29mr3312273wrr.12.1677624763370; Tue, 28 Feb 2023 14:52:43 -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 t5-20020a5d6a45000000b002c5706f7c6dsm10891626wrw.94.2023.02.28.14.52.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Feb 2023 14:52:42 -0800 (PST) Message-ID: <5751ca20-9848-af42-bd1d-c7671b5796db@redhat.com> Date: Tue, 28 Feb 2023 23:52:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit To: SeongJae Park Cc: "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 References: <20230228223859.114846-1-sj@kernel.org> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20230228223859.114846-1-sj@kernel.org> 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: cogmmn3u644qbt8jugjiwzk64jhxhqwp X-Rspamd-Queue-Id: C5128180006 X-HE-Tag: 1677624768-461436 X-HE-Meta: U2FsdGVkX19IA9+4i1m8+M7sB0xUc6s+OjZeigadVjnJq1TpxK8uwqhSeS9aGb6mB6Am0dHv5GeF0OCVAcocMTrbRMpCBDv9lIKz3LcC7mCco8FO+bXFLYPzOSOIOB/2WTNIjrFbrg/F8kn0AZE61CfE0Qle6tOlSbtBX1KzWEP75dhQwpuwsmGPq0fcuS9u1EkxYEYcNiVkdvEwirHeAXMp+tziOu4U5IRAUsBQpX1iUQK2RB0sBoCjYWP1ZtuDcao74ckyWSMkNdsilzgKLkMZ/C6N9snGsPnsyyUC8zP1wfyLZcrhGRcZl++Ij22v95cWOuco+KzTEq/xrdDy4Zo6Kt7zwAqcbRNj3z7UxA5MA41EbyouRDaQCO19WmUGi8srjAGywxNWPF29aG8jh8ehFATlBCo6ppkrUIrQo1eJznLXWYNEPhyZza8uueNdrXxfqwrLydeohqFVu/a9tSRUFItcBOU/Kvs3yh5NDFUajWIOq+jAolkPv1jLMev/lHXM4zPOLo6qmj7QzUeV4B9rL/73WBICwPBjYKVxMpQCzOqPw2lKgDyiy/SvRzet+utvrZieoSmCkjf/I4xbwI9k4eT4SOqmC+7TEnIpyHeSgMhE8dvxOrBnMuHjexckBXeJkUMMcI4+sy3Mb3UFyFDSEJXPxdgfSsimH7SBle7ddrEk4YoVXvMmlfC++y1/+4UoncK5SPuzQSEy4BeTKe4NVjhx07n9ko8oHxivm6O/ljtj/tC254FT4I/3+SwwaCnupSY50z1eOzMCBt8qOWnabuaz7mbLGRyL9HWi7naIvrejdetjDFiacgtH46cjRITu3djhh43dHR4vGq5AxA/OlXTwv0KiceyPlWGBeXh66Tuv443+SItZUwzIWSY7wA1IzHfgawSBZld9j4fh8jLyUuMwtbxnoaOxLRi/jgTBFo1phNPT9qbgzGRNIJylH7iZ6uq34d3r0ccaYmZ jVGQO8eX 4GuBj7mw6YvOMgCmLjbRCnnH+CyrHZJMjBs4TXcxXHIcWT4rRXX4alzUe7yzPyN6ZheDCeOD5TgvOu+j85UroUMjCwSFh/quOxU5ICKjPgY3XdGjTGmPRQh6wPoxO67xUudiE8f0OG/JdAwsRPFY/fnxEqiSZaxSbMsi5zR264VZi8AHVYr9717ejyFL3hEnOs0VUBYgCEK/CtKtb7/BodRjlu+AaI0PJvI8n9pS34lTVTu+GXzjFYqdVBmJe8cW7ELNyIwcsnMXN+OxSIAZoc3+dyuBCIHC0nCm39FLQCX0eMtXTISK5uwdkYyuyXWc8drBxlrXp8mmQZssnOaP6ZMHgc3/odYj+uLLPjoYeIU2Z9B6xf1cGz77EsiC5eoipH7foWYpJzm51sgTR1V+weS3X66/S0730Ij+vPeeiQpSIx2Q= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 :) > Hope to attend this session and discuss about that together. Absolutely! -- Thanks, David / dhildenb