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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CDC5EC32771 for ; Wed, 15 Jan 2020 22:54:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7D7422081E for ; Wed, 15 Jan 2020 22:54:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7D7422081E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DADEC8E0011; Wed, 15 Jan 2020 17:54:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D5F8A8E0003; Wed, 15 Jan 2020 17:54:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C4C9C8E0011; Wed, 15 Jan 2020 17:54:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id AD6D18E0003 for ; Wed, 15 Jan 2020 17:54:08 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 5C6AE180AD81F for ; Wed, 15 Jan 2020 22:54:08 +0000 (UTC) X-FDA: 76381373376.25.talk70_7b60223290a37 X-HE-Tag: talk70_7b60223290a37 X-Filterd-Recvd-Size: 3572 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Wed, 15 Jan 2020 22:54:07 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2020 14:54:05 -0800 X-IronPort-AV: E=Sophos;i="5.70,323,1574150400"; d="scan'208";a="218313203" Received: from ahduyck-desk1.jf.intel.com ([10.7.198.76]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2020 14:54:05 -0800 Message-ID: <4b8671d16573307da09afc56030c2a5f5a9c45bf.camel@linux.intel.com> Subject: [LSF/MM TOPIC] Free Page Reporting From: Alexander Duyck To: lsf-pc@lists.linux-foundation.org, MM Mailing List Date: Wed, 15 Jan 2020 14:54:05 -0800 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.5 (3.32.5-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Guests running on a KVM hypervisor don't normally have physical memory assigned to them, instead the host allocates virtual memory for the guest. As the guest uses memory, physical pages are faulted in to back the virtual memory, and when under memory pressure the host can swap those pages out to disk freeing them up for other uses. As a result, a guest may suffer from performance degradation when the host memory is over-committed and under memory pressure since a guest's memory may be swapped to disk when it next attempts to access it. In addition the memory pressure the host is experiencing may not be genuine as some guests may no longer be using the pages currently allocated to them. The current solution to this is memory ballooning, however that requires manual intervention to trigger and may result in performance degradation on the guest if it has need of the memory being pulled into the balloon. Free page hinting/reporting has been discussed as a solution to these issues for some time with one of the earliest known mentions being back in 2011 at the KVM Forum[0]. The goal with free page reporting is to enable memory over-commit while not taxing the resources on the system by proactively freeing the unused memory from each guest instead of waiting for the host to swap it out. The advantage is that unused guests can return their memory resources to the host without the need of intervention at the host level and avoid the costly overhead for writing or reading that memory from disk. I have been working on enabling a guest to notify the host of free or unused pages, with v16 of the patch set being the most recent version[1]. The code itself has gone though a number of changes over the last year, and prior to starting this work there has already been a documented history[2] of others working on similar efforts. The goals of the discussion would be: - Identify any remaining gaps to be addressed in the current solution - Discuss next steps, such as: - Applying proactive memory pressure in guests - Providing a mechanism to notify guest of need for memory pressure - Rebasing page hinting to make use of page reporting [0]: https://www.linux-kvm.org/images/f/ff/2011-forum-memory-overcommit.pdf [1]: https://lore.kernel.org/lkml/20200103210509.29237.18426.stgit@localhost.localdomain/ [2]: https://lore.kernel.org/lkml/29f43d5796feed0dec8e8bb98b187d9dac03b900.camel@linux.intel.com/