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 37AE3C33CA1 for ; Wed, 5 Feb 2020 09:35:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F334821741 for ; Wed, 5 Feb 2020 09:35:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F334821741 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 73F2C6B0096; Wed, 5 Feb 2020 04:35:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EFD26B0099; Wed, 5 Feb 2020 04:35:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5DDBA6B009A; Wed, 5 Feb 2020 04:35:12 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0195.hostedemail.com [216.40.44.195]) by kanga.kvack.org (Postfix) with ESMTP id 435F66B0096 for ; Wed, 5 Feb 2020 04:35:12 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id DEA15180AD802 for ; Wed, 5 Feb 2020 09:35:11 +0000 (UTC) X-FDA: 76455564822.13.soda35_2d3f7a17b6362 X-HE-Tag: soda35_2d3f7a17b6362 X-Filterd-Recvd-Size: 4038 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Wed, 5 Feb 2020 09:35:10 +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 fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Feb 2020 01:35:09 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,405,1574150400"; d="scan'208";a="264160600" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by fmsmga002.fm.intel.com with ESMTP; 05 Feb 2020 01:35:09 -0800 Received: from fmsmsx124.amr.corp.intel.com (10.18.125.39) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 01:35:09 -0800 Received: from shsmsx153.ccr.corp.intel.com (10.239.6.53) by fmsmsx124.amr.corp.intel.com (10.18.125.39) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 5 Feb 2020 01:35:09 -0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.126]) by SHSMSX153.ccr.corp.intel.com ([169.254.12.97]) with mapi id 14.03.0439.000; Wed, 5 Feb 2020 17:35:07 +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//fmaAABDM2dD//3whAP//eIgwgACMLgD//3kPIA== Date: Wed, 5 Feb 2020 09:35:06 +0000 Message-ID: <286AC319A985734F985F78AFA26841F73E41F490@shsmsx102.ccr.corp.intel.com> References: <91270a68-ff48-88b0-219c-69801f0c252f@redhat.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> <286AC319A985734F985F78AFA26841F73E41F367@shsmsx102.ccr.corp.intel.com> <605bef3e-373f-f39a-4849-930326564b5b@redhat.com> <286AC319A985734F985F78AFA26841F73E41F3DE@shsmsx102.ccr.corp.intel.com> In-Reply-To: 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 5:23 PM, David Hildenbrand wrote: > So, if you run a TCG guest and use it with free page reporting, the race = is > possible? So the correctness depends on two dirty bitmaps in the hypervis= or > and how they interact. wow this is fragile. > Not sure how TCG tracks the dirty bits. But In whatever implementation, the= hypervisor should have already dealt with the race between he current round and the previous round= dirty recording. (the race isn't brought by this feature essentially) Best, Wei From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wang, Wei W" Subject: RE: Balloon pressuring page cache Date: Wed, 5 Feb 2020 09:35:06 +0000 Message-ID: <286AC319A985734F985F78AFA26841F73E41F490@shsmsx102.ccr.corp.intel.com> References: <91270a68-ff48-88b0-219c-69801f0c252f@redhat.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> <286AC319A985734F985F78AFA26841F73E41F367@shsmsx102.ccr.corp.intel.com> <605bef3e-373f-f39a-4849-930326564b5b@redhat.com> <286AC319A985734F985F78AFA26841F73E41F3DE@shsmsx102.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: virtualization-bounces@lists.linux-foundation.org Sender: "Virtualization" To: David Hildenbrand , "Michael S. Tsirkin" Cc: "virtualization@lists.linux-foundation.org" , Tyler Sanderson , "linux-mm@kvack.org" , Nadav Amit , David Rientjes , Alexander Duyck , Michal Hocko List-Id: virtualization@lists.linuxfoundation.org On Wednesday, February 5, 2020 5:23 PM, David Hildenbrand wrote: > So, if you run a TCG guest and use it with free page reporting, the race is > possible? So the correctness depends on two dirty bitmaps in the hypervisor > and how they interact. wow this is fragile. > Not sure how TCG tracks the dirty bits. But In whatever implementation, the hypervisor should have already dealt with the race between he current round and the previous round dirty recording. (the race isn't brought by this feature essentially) Best, Wei