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 EE283C7EE31 for ; Tue, 28 Feb 2023 22:39:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 770E66B0072; Tue, 28 Feb 2023 17:39:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 721786B0073; Tue, 28 Feb 2023 17:39:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 610616B0074; Tue, 28 Feb 2023 17:39:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 513736B0072 for ; Tue, 28 Feb 2023 17:39:06 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 0C05AA0517 for ; Tue, 28 Feb 2023 22:39:06 +0000 (UTC) X-FDA: 80518167492.21.885E7A0 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf16.hostedemail.com (Postfix) with ESMTP id 36F4C180016 for ; Tue, 28 Feb 2023 22:39:03 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SbHQ3IYf; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of sj@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677623944; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=omn+4wFmeLsJMgbOC4V16xXMtKHeGun8qyk0xS2txg8=; b=jIi1yYEzoQZ/esuhs9UpJgOQvehySoEO3+oihgNRcYydDNHqb6i9Cbz6KVKS/yhg1raNp6 kgjFM+Xgysx8OUgfpuTHN8M4L/tdDFSIUa8qwnkdpxA4JQNhjGTqwjSjg2luCLpb9DmDZ5 /8JuQ8sZVwPPsi2JUORQu+Of4tu6yOc= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SbHQ3IYf; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of sj@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677623944; a=rsa-sha256; cv=none; b=rRU48RH0m4XBBI+sgbrrxJqf95IBm9RVaItEqb7EOH7lh28y3l5VxTtiKfrCbPPx0vMAVb y1ej6yZTLrW5R0F7wUw2ZrfWr44Hk2X+NTyPnrGxzJI9hNXMyHAqYoBnSMzAQFwXkW5Ep1 NI+zoV3oyUrD93hOf/a0pdLrWriHt3M= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 59CA7B80EDB; Tue, 28 Feb 2023 22:39:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FBA8C4339B; Tue, 28 Feb 2023 22:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677623942; bh=d4lBrhKPB0jOyh0au68MrD6u+KOd9aGeSx3XzB0078I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SbHQ3IYfgGH2M4K+4QG0XJHcQXbrNWbSLhU3DR3E7/36PUh/kVUjiPvVljfy9FSwA PUzHJ/S5K06AfV9buE6DKOmz9fr552kLm2Mg/aAq+fktL17F5zg0OUNp6pXk4X3k+v SxDH5Q4jTMCIZ+Ug9U+1BLJiBEobpSUsPoaIqx2sJHcmro6cDDUJPXeV/tuLRJ/Ulj 3Ph0/+D14/qrnw/tPGM0HKnzjHMIRN7w0t/cjxowauVZFs71V9erKshha4b05zQwuJ Xbv3zpPSZTxiT/KKB6p10+NaL+N59T4HdBfqp7sQdjPOCxLbSMUHp03hYf6hMn0UGY EkGgIdQbAXG0w== From: SeongJae Park To: David Hildenbrand 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 Subject: Re: [LSF/MM/BPF TOPIC] VM Memory Overcommit Date: Tue, 28 Feb 2023 22:38:59 +0000 Message-Id: <20230228223859.114846-1-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 36F4C180016 X-Stat-Signature: q4d836zoofe1r8nzqwjm7gf6tij1tbb5 X-HE-Tag: 1677623943-323332 X-HE-Meta: U2FsdGVkX1/PaZcgCFH0Ce3cliBy/XJZOmUcJYxLNFmgqP3H40k3NHQw54cv20XxGxuZN8do6Z0aDmbB12+AC5rKpn45Zt7zp6E8f50NXlIXWK/MfM/xbMzpncbTJvLgPFPomNduQNYcr6AZ/1kX/hs8YtGhf0A5qQMp15Exg4r2OSYb8fcSLwfMBw3FOWiU3NhsUZprGGopFfxspMcxH+2Y1GaMpB9lX4fkqTRdltLSzGY2j+ZQZSGYt0ZiZNQMJPDFwGF2u+o3QULYhKYX+GoC94PI9ONy9jSp5neHmzjbQ4e2RafxQaT2EpeUSAL1DQMAb021qJf8UeeINKRduWVZ5qhidL5vIPTS7rRuETptr1xPdrESTjiT36m6N7vmIbI71+ewpeArI65uXkdSlDz78nzuPsBQt/yraV0yJHDurK/B0WpUJVteZh/S2YMxcXFcEOG2Vcbz4bGJ1NVWdsrMd7IOgoV/Z4YA6yZHLZdGUewWR98kneOcAHlxDImL7rbZ7sq1ReTP00LpL8EhkP+jhDEjf3XUB1rVV7fgvJD0+l2Wb4ZZq2QhYkyin/z3XNQYBxxm0V9fq+VsZatl4c+hPktEolKXiNaO0mCbhRS5L0rYP37Cqcdt7lfgWIb5zxgm5bCV/02DBPqZXYIlXKTd8qX9jQMQUyQMAxS8nOYMt5y73HemQ8WwLdcOPvcYiIFIOqIAX0iIiqBBKLjVYs1wbt2A6BQqIqISWvGM+7nVBR5SxLh2m9luLLs5o9IC7Th7NzOXOrAGJvjGogncfXmHGjeZDyDSd/C8j3T6zoEOXVrE2JoW0DQyB0+XNdz/yZQZfJiT3O/yMFaRI2Ci3P5Ej3uKzxrxuvttEDbhNi5Goq6l1HMsgbZJ4brQLrqq74g5ldEvYDBErI1x2hLKt10qiE5+EOgMw7jnJZjpZdCC4UIhUbHV+4By+G3RmuC3r6xJLkDON5+u5odmm6L V6fOfHiw ATDEjAnmXF+s6+6Imqa/q2bfzW668vu8S3rQZEuoKbmohb/WjK2Gk7ok/btCxJOdKl4b1xRNsr2vDo/lT/CFXUFNu5wSyZ7PDjeuld5O5kZzuG6zp9laj97uNKa8TZR0cE0MmMJrRAQKmxlYVqMEsTimEVmlAHKkL4SiJx67Gnsm5oP7WbBMLxzy81JqigHs7ZaBmw1Dsa+dBRz5rWeY6ZS0NjZYSMjXohNw0gQaiisO3nJxg7iSMrveKbFhoP7u4zwiLjGsh4yaq+ATJDvmWn19BoySzd3cOd9tExlamNkog60PEcmdh5Xtzm0Ui6dPAxDKqNsnS6Znns3C4F6Xh2jc9fK+p+RULIdLzb4oubg4q43ChGnMxCveqBliklnFdNSJ8VcFy7kUvyX+RQUoQK9AlOA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000044, 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 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. Hope to attend this session and discuss about that together. [1] https://docs.kernel.org/admin-guide/mm/damon/reclaim.html Thanks, SJ > > -- > Thanks, > > David / dhildenb > >