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 C7BE9C33CA1 for ; Wed, 5 Feb 2020 08:54:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 928F12082E for ; Wed, 5 Feb 2020 08:54:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 928F12082E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 22C916B0074; Wed, 5 Feb 2020 03:54:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DD096B0075; Wed, 5 Feb 2020 03:54:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0CC8B6B0078; Wed, 5 Feb 2020 03:54:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id E7A526B0074 for ; Wed, 5 Feb 2020 03:54:45 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 70EBF4DA7 for ; Wed, 5 Feb 2020 08:54:45 +0000 (UTC) X-FDA: 76455462930.27.sack13_80b5c5003fc27 X-HE-Tag: sack13_80b5c5003fc27 X-Filterd-Recvd-Size: 4613 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Wed, 5 Feb 2020 08:54:44 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2020 00:54:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,405,1574150400"; d="scan'208";a="264148853" Received: from fmsmsx103.amr.corp.intel.com ([10.18.124.201]) by fmsmga002.fm.intel.com with ESMTP; 05 Feb 2020 00:54:40 -0800 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by FMSMSX103.amr.corp.intel.com (10.18.124.201) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 00:54:40 -0800 Received: from shsmsx107.ccr.corp.intel.com (10.239.4.96) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 00:54:40 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.126]) by SHSMSX107.ccr.corp.intel.com ([169.254.9.46]) with mapi id 14.03.0439.000; Wed, 5 Feb 2020 16:54:38 +0800 From: "Wang, Wei W" To: David Hildenbrand , "Michael S. Tsirkin" CC: Nadav Amit , Alexander Duyck , Tyler Sanderson , "virtualization@lists.linux-foundation.org" , David Rientjes , "linux-mm@kvack.org" , "Michal Hocko" Subject: RE: Balloon pressuring page cache Thread-Topic: Balloon pressuring page cache Thread-Index: AQHV1jovoZrFI2PKjUOgo5GIAcuyoKgA6/YAgACRPICAAUzXAIAAibNg///JVwCABdc9AIAANGSAgAAETACAAGklgIAAo12AgAABfACAAGGxgIABj+gw//+atoCAAIwXoA== Date: Wed, 5 Feb 2020 08:54:38 +0000 Message-ID: <286AC319A985734F985F78AFA26841F73E41F306@shsmsx102.ccr.corp.intel.com> References: <91270a68-ff48-88b0-219c-69801f0c252f@redhat.com> <75d4594f-0864-5172-a0f8-f97affedb366@redhat.com> <286AC319A985734F985F78AFA26841F73E3F8A02@shsmsx102.ccr.corp.intel.com> <20200203080520-mutt-send-email-mst@kernel.org> <5ac131de8e3b7fc1fafd05a61feb5f6889aeb917.camel@linux.intel.com> <539B606A-A0CA-4AA4-B99A-759C874A1EF8@vmware.com> <20200204033657-mutt-send-email-mst@kernel.org> <286AC319A985734F985F78AFA26841F73E41F0F0@shsmsx102.ccr.corp.intel.com> <1eff30a0-a38a-cd45-2fc1-80cfd0bf5f04@redhat.com> In-Reply-To: <1eff30a0-a38a-cd45-2fc1-80cfd0bf5f04@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 Wednesday, February 5, 2020 4:19 PM, David Hildenbrand wrote: > Yes, I agree with you. Yet, I am thinking about one > (unlikely?impossible?) scenario. Can you refresh my brain why that cannot > happen (IOW, why we don't have to wait for the host to process the > request)? >=20 > 1. Guest allocates a page and sends it to the host. > 2. Shrinker gets active and releases that page again. > 3. Some user in the guest allocates and modifies that page. After that, i= t is > done using that page for the next hour. > 4. The host processes the request and clears the bit in the dirty bitmap. > 5. The guest is being migrated by the host. The modified page is not bein= g > migrated. Whenever the guest modifies a page during migration, it will be captured by= the dirty logging and the hypervisor will send the dirtied the page in the foll= owing round. Just more thoughts to clarify the difference. I think it's all about the pa= ge ownership. For VIRTIO_BALLOON_F_FREE_PAGE_HINT, the guest always owns the page, so host should not use or unmap the page. For VIRTIO_BALLOON_F_REPORTING or the legacy balloon inflation, guest intends to transfer the ownership of the underlying physical page to = the host, that's why host and guest needs a sync about - if the "ownership" transfer = completes or not. Best, Wei