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 26E29C35249 for ; Wed, 5 Feb 2020 09:00:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EB82A2082E for ; Wed, 5 Feb 2020 09:00:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EB82A2082E 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 7F6086B0082; Wed, 5 Feb 2020 04:00:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A53E6B0083; Wed, 5 Feb 2020 04:00:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66EB46B0085; Wed, 5 Feb 2020 04:00:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0068.hostedemail.com [216.40.44.68]) by kanga.kvack.org (Postfix) with ESMTP id 4CBE76B0082 for ; Wed, 5 Feb 2020 04:00:10 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id DD184181AC9CC for ; Wed, 5 Feb 2020 09:00:09 +0000 (UTC) X-FDA: 76455476538.06.brick33_1e6fa38749632 X-HE-Tag: brick33_1e6fa38749632 X-Filterd-Recvd-Size: 4588 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Wed, 5 Feb 2020 09:00:08 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2020 01:00:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,405,1574150400"; d="scan'208";a="279311234" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by FMSMGA003.fm.intel.com with ESMTP; 05 Feb 2020 01:00:07 -0800 Received: from fmsmsx158.amr.corp.intel.com (10.18.116.75) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 01:00:07 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by fmsmsx158.amr.corp.intel.com (10.18.116.75) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 01:00:07 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.126]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.76]) with mapi id 14.03.0439.000; Wed, 5 Feb 2020 17:00:05 +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//+atoCAAIwXoP//fmaAABDM2dA= Date: Wed, 5 Feb 2020 09:00:04 +0000 Message-ID: <286AC319A985734F985F78AFA26841F73E41F367@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> <286AC319A985734F985F78AFA26841F73E41F306@shsmsx102.ccr.corp.intel.com> <2b388a78-79cd-f99a-6f87-6446dcb4b819@redhat.com> In-Reply-To: <2b388a78-79cd-f99a-6f87-6446dcb4b819@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:57 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)? > >> > >> 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, it is done using that page for the next hour. > >> 4. The host processes the request and clears the bit in the dirty bitm= ap. > >> 5. The guest is being migrated by the host. The modified page is not > >> being 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 following round. >=20 > Please explain why the steps I outlined don't apply esp. in the last roun= d. > Your general statement does not explain why this race can't happen. >=20 The guest is stopped in the last round, thus no page will be modified at th= at time. Best, Wei