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=-5.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_MUTT autolearn=ham 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 A91A9C28CC0 for ; Sat, 1 Jun 2019 03:35:49 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 5DA8D270D6 for ; Sat, 1 Jun 2019 03:35:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5DA8D270D6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([127.0.0.1]:52274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hWuo8-0004N9-0e for qemu-devel@archiver.kernel.org; Fri, 31 May 2019 23:35:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50913) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hWunL-0003zf-Bw for qemu-devel@nongnu.org; Fri, 31 May 2019 23:35:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hWunK-0000i8-5p for qemu-devel@nongnu.org; Fri, 31 May 2019 23:34:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50796) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hWunJ-0000hI-Vc for qemu-devel@nongnu.org; Fri, 31 May 2019 23:34:58 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0B810C04B2F6; Sat, 1 Jun 2019 03:34:54 +0000 (UTC) Received: from xz-x1 (ovpn-12-71.pek2.redhat.com [10.72.12.71]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3405719C67; Sat, 1 Jun 2019 03:34:50 +0000 (UTC) Date: Sat, 1 Jun 2019 11:34:41 +0800 From: Peter Xu To: "Dr. David Alan Gilbert" Message-ID: <20190601033441.GB4958@xz-x1> References: <20190507031703.856-1-richardw.yang@linux.intel.com> <20190531164337.GK3169@work-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190531164337.GK3169@work-vm> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Sat, 01 Jun 2019 03:34:56 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH] migratioin/ram: leave RAMBlock->bmap blank on allocating X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel@nongnu.org, Wei Yang , quintela@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, May 31, 2019 at 05:43:37PM +0100, Dr. David Alan Gilbert wrote: > * Wei Yang (richardw.yang@linux.intel.com) wrote: > > During migration, we would sync bitmap from ram_list.dirty_memory to > > RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap(). > > > > Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this > > means at the first round this sync is meaningless and is a duplicated > > work. > > > > Leaving RAMBlock->bmap blank on allocating would have a side effect on > > migration_dirty_pages, since it is calculated from the result of > > cpu_physical_memory_sync_dirty_bitmap(). To keep it right, we need to > > set migration_dirty_pages to 0 in ram_state_init(). > > > > Signed-off-by: Wei Yang > > I've looked at this for a while, and I think it's OK, so > > Reviewed-by: Dr. David Alan Gilbert > > Peter, Juan: Can you just see if there's arny reason this would be bad, > but I think it's actually more sensible than what we have. I really suspect it will work in all cases... Wei, have you done any test (or better, thorough tests) with this change? My reasoning of why we should need the bitmap all set is here: https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg07361.html Regards, -- Peter Xu