From nobody Fri May 17 06:43:26 2024 Delivered-To: importer@patchew.org Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org ARC-Seal: i=1; a=rsa-sha256; t=1590984285; cv=none; d=zohomail.com; s=zohoarc; b=GtsdwBlNFXeAe7jotdWabh+vVdYG+g3fUVxOCWviKv4QVv8n1l2V2Vaj8VLY8OJzKAvoNXVUphOJe23KkVwxTIZR+rMdjM0jyq4rVl4ct4z8RuqxnXvlCxlVfJ300Ux8wf/t9o7jUlGuR4dCa6bce+9zHqj085BUXBPw+Ks6oSA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1590984285; h=Content-Type:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=7yriWp0cG6mGwV4GUlac1DOYPrvmiQaEH5RriH8OI04=; b=Rxwtp54ppjP3NDjtwEHg2Cm+B1l9PEv1XMFdyXpe/Vn6+N1iWuH8Uol1skEwJ4Z08JEi4Jy0xTqIxP871ETMx2psslfVhv+v4UmJKb5Y+EgtGP2mapEvS/DSVSYsizC7hAdflgHJxzhDLiNnDt/S9bdtw2QCHApVdHQQDmkbDt8= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 159098428551359.05521940327776; Sun, 31 May 2020 21:04:45 -0700 (PDT) Received: from localhost ([::1]:33720 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jfbgp-0006a5-Is for importer@patchew.org; Mon, 01 Jun 2020 00:04:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57112) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jfbfq-0005wl-3w; Mon, 01 Jun 2020 00:03:42 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:3771 helo=huawei.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jfbfo-00081y-GG; Mon, 01 Jun 2020 00:03:41 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 25604FEA423AB5663262; Mon, 1 Jun 2020 12:03:30 +0800 (CST) Received: from DESKTOP-5IS4806.china.huawei.com (10.173.221.230) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.487.0; Mon, 1 Jun 2020 12:03:21 +0800 From: Keqian Zhu To: , Subject: [PATCH] migration: Count new_dirty instead of real_dirty Date: Mon, 1 Jun 2020 12:02:50 +0800 Message-ID: <20200601040250.38324-1-zhukeqian1@huawei.com> X-Mailer: git-send-email 2.8.4.windows.1 MIME-Version: 1.0 X-Originating-IP: [10.173.221.230] X-CFilter-Loop: Reflected Received-SPF: pass (zohomail.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Received-SPF: pass client-ip=45.249.212.191; envelope-from=zhukeqian1@huawei.com; helo=huawei.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/01 00:03:30 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , Chao Fan , Keqian Zhu , wanghaibin.wang@huawei.com, Juan Quintela Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" DIRTY_LOG_INITIALLY_ALL_SET feature is on the queue. This fixs the dirty rate calculation for this feature. After introducing this feature, real_dirty_pages is equal to total memory size at begining. This causing wrong dirty rate and false positive throttling. BTW, real dirty rate is not suitable and not very accurate. 1. For not suitable: We mainly concern on the relationship between dirty rate and network bandwidth. Net increasement of dirty pages makes more sense. 2. For not very accurate: With manual dirty log clear, some dirty pages will be cleared during each peroid, our "real dirty rate" is less than real "real dirty rate". Signed-off-by: Keqian Zhu --- include/exec/ram_addr.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h index 5e59a3d8d7..af9677e291 100644 --- a/include/exec/ram_addr.h +++ b/include/exec/ram_addr.h @@ -443,7 +443,7 @@ static inline uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock *rb, ram_addr_t start, ram_addr_t length, - uint64_t *real_dirty_pages) + uint64_t *accu_dirty_pages) { ram_addr_t addr; unsigned long word =3D BIT_WORD((start + rb->offset) >> TARGET_PAGE_BI= TS); @@ -469,7 +469,6 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock= *rb, if (src[idx][offset]) { unsigned long bits =3D atomic_xchg(&src[idx][offset], 0); unsigned long new_dirty; - *real_dirty_pages +=3D ctpopl(bits); new_dirty =3D ~dest[k]; dest[k] |=3D bits; new_dirty &=3D bits; @@ -502,7 +501,6 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock= *rb, start + addr + offset, TARGET_PAGE_SIZE, DIRTY_MEMORY_MIGRATION)) { - *real_dirty_pages +=3D 1; long k =3D (start + addr) >> TARGET_PAGE_BITS; if (!test_and_set_bit(k, dest)) { num_dirty++; @@ -511,6 +509,7 @@ uint64_t cpu_physical_memory_sync_dirty_bitmap(RAMBlock= *rb, } } =20 + *accu_dirty_pages +=3D num_dirty; return num_dirty; } #endif --=20 2.19.1