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=-8.3 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 16525C35247 for ; Wed, 5 Feb 2020 18:43:19 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C273020674 for ; Wed, 5 Feb 2020 18:43:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ST99ESW/" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C273020674 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5CA8D6B00BA; Wed, 5 Feb 2020 13:43:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 554686B00BD; Wed, 5 Feb 2020 13:43:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 443AB6B00BE; Wed, 5 Feb 2020 13:43:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0229.hostedemail.com [216.40.44.229]) by kanga.kvack.org (Postfix) with ESMTP id 238326B00BA for ; Wed, 5 Feb 2020 13:43:18 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id C967734A4 for ; Wed, 5 Feb 2020 18:43:17 +0000 (UTC) X-FDA: 76456946034.17.power77_1cb3aef4b9701 X-HE-Tag: power77_1cb3aef4b9701 X-Filterd-Recvd-Size: 7963 Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Wed, 5 Feb 2020 18:43:17 +0000 (UTC) Received: by mail-vs1-f49.google.com with SMTP id p6so2007020vsj.11 for ; Wed, 05 Feb 2020 10:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RCPUsF6p09/nvGyzqGEB4sF6CrQ91hGBN8Tz6aQ941g=; b=ST99ESW/pOg2Hr3KW1GGzG6ZllnEKzoPnGtfnJ3ktWuJRNMLcryC9z3/7vrmo88S4i CkT48Ipmn2gQ7OqQ+OHVq+QZBgXx8gF48vnYfm9gn5BbP4QSZpINoSz8CXolMwzaqJgD +cAkLBy3UZWS0r4RGk35bDiebUk2456s8P4dceBnnjMxiRo/mJBqSQct9thYmUS0op6w HvjEQ+VGjTyZmGV1kkrvrkTKWhUjIXOFMdP3P2SCZs2OIfFE1lFcWcmTYapvKetqygPw 45YRK0spgvwAMCvWkXRrL49B05L+JWuDCAFGgBoLbW5INbsEk//Slr3EBNGpwzaIY/er 3BwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RCPUsF6p09/nvGyzqGEB4sF6CrQ91hGBN8Tz6aQ941g=; b=Q8pNdy8yvjUIRwdXnFrDJ+z3oQjVVVVIi8QROhe4xyqqa4pZEfSOKEZvzhmMqyuq7L oC7zeZBCttoq6FfGh/NOdhtty51x5r5KYrfF9YJS0cdZzMDNBiwDW5cFE76Xdnh+A+pc YdGGdM8rJRB0NEBAtVzVlwjYIA4GHg3EDwiNpWVNZ+1IqyPeE3IThiBrG46kyX978uAp qWy6jOIYXUncv3OWiqNpJliU6kDOGbdAUfveFkuUYIrvf4F/K3v7KZUWvFhw0XCE1ZwO izioltNgySHGRuASaVl0xUYq4js4qj4FyKOGoUXwCDCEw9lSgVMxI74fHdByfxw/vYAN y/hQ== X-Gm-Message-State: APjAAAUWbIqtvbqvK/lICvIXLJr3QTOOc7KpOgi2r44rJyr/032a6Erk 1F0wOVifw3DUv2qrv8kNIlRH8xaDaWvyDP7GJ1xLCg== X-Google-Smtp-Source: APXvYqwcJlpadFVuJlED2dxL9ifbACdugCA/sYQVXhPp24DyMY932vfzXz/FkuZKD8lQ9bfuLbN663S+M/MTOEPUzXE= X-Received: by 2002:a67:e3b3:: with SMTP id j19mr22827611vsm.41.1580928196513; Wed, 05 Feb 2020 10:43:16 -0800 (PST) MIME-Version: 1.0 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> <286AC319A985734F985F78AFA26841F73E41F367@shsmsx102.ccr.corp.intel.com> In-Reply-To: <286AC319A985734F985F78AFA26841F73E41F367@shsmsx102.ccr.corp.intel.com> From: Tyler Sanderson Date: Wed, 5 Feb 2020 10:43:04 -0800 Message-ID: Subject: Re: Balloon pressuring page cache To: "Wang, Wei W" Cc: David Hildenbrand , "Michael S. Tsirkin" , Nadav Amit , Alexander Duyck , "virtualization@lists.linux-foundation.org" , David Rientjes , "linux-mm@kvack.org" , Michal Hocko Content-Type: multipart/alternative; boundary="000000000000920dc4059dd887fa" 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: --000000000000920dc4059dd887fa Content-Type: text/plain; charset="UTF-8" On Wed, Feb 5, 2020 at 1:00 AM Wang, Wei W wrote: > 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 > bitmap. > > >> 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. > > > > Please explain why the steps I outlined don't apply esp. in the last > round. > > Your general statement does not explain why this race can't happen. > > > > The guest is stopped in the last round, thus no page will be modified at > that time. > Isn't the hint only useful during the *first* round? After the first round if a page becomes free then we need to update the copy at the migration destination, so freeing a page that previously had contents should mark it dirty. > > Best, > Wei > --000000000000920dc4059dd887fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Feb 5, 2020 at 1:00 AM Wang, = Wei W <wei.w.wang@intel.com&= gt; wrote:
On We= dnesday, 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 hos= t 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. A= fter
> >> that, it is done using that page for the next hour.
> >> 4. The host processes the request and clears the bit in the d= irty bitmap.
> >> 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 di= rtied the
> page in the following round.
>
> Please explain why the steps I outlined don't apply esp. in the la= st round.
> Your general statement does not explain why this race can't happen= .
>

The guest is stopped in the last round, thus no page will be modified at th= at time.

Isn't the hint only useful= during the first round?
After the first round if a page b= ecomes free then we need to update the copy at the migration destination, s= o freeing a page that previously had contents should mark it dirty.
=C2=A0

Best,
Wei
--000000000000920dc4059dd887fa--