Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp1152530ybh; Wed, 11 Mar 2020 18:47:02 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvcrVs2y+P+h82o1gkyFxgY2sHtx/rfpJBNz9qgHWYvvNQBkkLT6n8H2TsSxnX1dvUZ1TrF X-Received: by 2002:aca:f12:: with SMTP id 18mr1006974oip.126.1583977622354; Wed, 11 Mar 2020 18:47:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583977622; cv=none; d=google.com; s=arc-20160816; b=OPTxMP7WEcKyZmxDjkkovUr2HB3qq1CKGwiJFpOBn77F+iSSSE7F6MdGYpPVFX7Y/p 8P6xYBTd4M+IqOMiJhXutjoojo6a4R7ktPcde/Vh5/Hn9vF4IFy81HYMGE3Hws2y5b2Q vROhhvLySG5SIpjbSr5A1Ku8gOyv4klZLjUpxN1jc0xTaaKAoSMAZzG5MRGQxyC7sOaF hesjs8wDmgqWVkfn50jc5CkROFl14cXw6gwsw+H/K+/lHF+m+YmZIC4YLU9Rs0c+8UFM QUrT++4rSpMl1O3nKCtZH9d2FwnPjEGrbPAtXB3a3gANKYl20ERFvfcFYlpdcIxzKm3m PIKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=tGwKwvCp1nDUCRwuW9Jg38hpBGLFIxmleU8PFIPbPBo=; b=nW3BXQt0GL724PXY/wuZ18ZtZL3/5Emg61Je0LUEhbyevIU4R0G860rl1wg95Aoq+K cB/dGgBPI2U+HTeNNkh7xrP2UNsddM1UmLb3JdtUsJDT12sk8bsiETXsKgb8Xpi2M82s ItORoatmUHlxvdt4YdB0W9C3je0QKhBzqRH/WtP6Kj9nNdliy91WiP+bq1Vt0PLemCkj T8mnSNn5nVL8B6L+RB5+TMlxAotl1GEaO9DUlGUP+ikYqisyMCQ2gnpRgjgw1yl6XWrO FQ2V89wcQ20gKlCUgqIMlka1onlLLjyo6OW4GLHvwfz1AMzhR9P8SnDW5g31bhT2Lg9c 7tjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a25si1963431oid.67.2020.03.11.18.46.49; Wed, 11 Mar 2020 18:47:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387630AbgCLBpn (ORCPT + 99 others); Wed, 11 Mar 2020 21:45:43 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:49984 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387571AbgCLBpm (ORCPT ); Wed, 11 Mar 2020 21:45:42 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 9DD712E01B64EC9C1957; Thu, 12 Mar 2020 09:45:36 +0800 (CST) Received: from [127.0.0.1] (10.173.221.230) by DGGEMS405-HUB.china.huawei.com (10.3.19.205) with Microsoft SMTP Server id 14.3.487.0; Thu, 12 Mar 2020 09:45:26 +0800 Subject: Re: [RFC] KVM: arm64: support enabling dirty log graually in small chunks To: "Zhoujian (jay)" , Marc Zyngier References: <20200309085727.1106-1-zhukeqian1@huawei.com> <4b85699ec1d354cc73f5302560231f86@misterjones.org> <64925c8b-af3d-beb5-bc9b-66ef1e47f92d@huawei.com> <9ddefc54-dd5b-0555-0aaa-00a3a23febcf@huawei.com> CC: "kvmarm@lists.cs.columbia.edu" , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Sean Christopherson , Paolo Bonzini , "James Morse" , Julien Thierry , Suzuki K Poulose , "Huangweidong (C)" , "wangxin (U)" From: zhukeqian Message-ID: <3238d495-8c13-4fbb-8e3d-c34e560ec9af@huawei.com> Date: Thu, 12 Mar 2020 09:45:25 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.173.221.230] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jay, On 2020/3/11 15:34, Zhoujian (jay) wrote: > > >> -----Original Message----- >> From: zhukeqian >> Sent: Wednesday, March 11, 2020 3:20 PM >> To: Marc Zyngier >> Cc: kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; >> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Zhoujian (jay) >> ; Sean Christopherson >> ; Paolo Bonzini ; >> James Morse ; Julien Thierry >> ; Suzuki K Poulose >> Subject: Re: [RFC] KVM: arm64: support enabling dirty log graually in small chunks >> >> Hi Marc, >> >> On 2020/3/10 21:16, Marc Zyngier wrote: >>> On 2020-03-10 08:26, zhukeqian wrote: >>>> Hi Marc, >>>> >>>> On 2020/3/9 19:45, Marc Zyngier wrote: >>>>> Kegian, >>> >>> [...] >>> >>>>> Is there a userspace counterpart to it? >>>>> >>>> As this KVM/x86 related changes have not been merged to mainline >>>> kernel, some little modification is needed on mainline Qemu. >>> >>> Could you please point me to these changes? >> I made some changes locally listed below. >> >> However, Qemu can choose to enable KVM_DIRTY_LOG_INITIALLY_SET or not. >> Here I made no judgement on dirty_log_manual_caps because I just want to >> verify the optimization of this patch. >> >> diff --git a/accel/kvm/kvm-all.c b/accel/kvm/kvm-all.c index >> 439a4efe52..1611f644a4 100644 >> --- a/accel/kvm/kvm-all.c >> +++ b/accel/kvm/kvm-all.c >> @@ -2007,14 +2007,16 @@ static int kvm_init(MachineState *ms) >> s->coalesced_pio = s->coalesced_mmio && >> kvm_check_extension(s, >> KVM_CAP_COALESCED_PIO); >> >> - s->manual_dirty_log_protect = >> + uint64_t dirty_log_manual_caps = >> kvm_check_extension(s, >> KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2); >> - if (s->manual_dirty_log_protect) { >> - ret = kvm_vm_enable_cap(s, >> KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2, 0, 1); >> + if (dirty_log_manual_caps) { >> + ret = kvm_vm_enable_cap(s, >> KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2, 0, >> + dirty_log_manual_caps); >> if (ret) { >> warn_report("Trying to enable >> KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 " >> "but failed. Falling back to the legacy mode. "); >> - s->manual_dirty_log_protect = false; >> + } else { >> + s->manual_dirty_log_protect = true; >> } >> } > > FYI: I had submitted a patch to the Qemu community some days ago: > https://patchwork.kernel.org/patch/11419191/ This is very helpful, thanks. > >>> >>>> As I tested this patch on a 128GB RAM Linux VM with no huge pages, >>>> the time of enabling dirty log will decrease obviously. >>> >>> I'm not sure how realistic that is. Not having huge pages tends to >>> lead to pretty bad performance in general... >> Sure, this has no effect on guests which are all of huge pages. >> >> For my understanding, once a guest has normal pages (maybe are initialized at >> beginning or dissloved from huge pages), it can benefit from this patch. > > Yes, I agree. > I will send PATCH v1 soon. > > > Regards, > Jay Zhou > > . > Thanks, Keqian