Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1428654ybz; Thu, 16 Apr 2020 09:00:43 -0700 (PDT) X-Google-Smtp-Source: APiQypIupHafB0nnQ6rKHIG6Xe070nkSW7OkipbhZMlrj5V6iunEnSgvveLc8V1pUBoL+6dmv0sL X-Received: by 2002:a17:906:7b53:: with SMTP id n19mr7862807ejo.244.1587052843267; Thu, 16 Apr 2020 09:00:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587052843; cv=none; d=google.com; s=arc-20160816; b=iVv0NuLBAI+tVje4rh8wSoxho2ig/u93mcxeExYQD9QQPpLQ7u7eoJ6sWpbbJF7tPd 48nJQ6PRQKKG64AiOS/YbNLWsEvNwyxOhcb0FX0/WFdmiWFz2nDwES5ZgrVMjl0UVT2+ fYZH3zf1ZxYubhQR8pN7xEf7EStzQc3Rx12t4lXB+FRE4W2QHduslvSqEgsf6hjxf14/ kHv1lLyvEqdSWK+jhV9qRez/i4L89FEkDVzyrCWT1eCzu8fanZoagli/1QAd54meQjwN sHN2gVb55RX7LcqiD7OyKJNtcAgLA06S/Tvu8S79ZCHlYqV/CVuwYHHu/ghUN0JVsPOS bB3A== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=nvu+MW6oZUAc4Rt+d0KHMjWiSPVqXx7NpVhFclBCSuA=; b=y3H5fWW0Mh3dcxBUC1vNuA6tgJ341RfWmpgYj9mDZSjgG2i6kOopbpc/rRtSW5NZ07 qu7D/ZkauK6Bc6obgGnUimTPba1aBpkyGNNjAgBhxiW56K/h+FFwORcO8Vf9VpCl527/ KZCrafAQ/OKoE43/SuCUZRWn7NdgBadmUB5MDkgiUGTKUJNih9VV4V+/1493rFSC+k79 2Ls3zwAwh+C2+byvPis4dtPt/RfRx4YDO+u3dNHANUMHIUvI0rZltsWSYZxvdnQInAcR WD8Zw0prCIZrX18bpYpzj6an203izBCBMZf1snwE1sBaI2Zv3N7cFXMY/zn7qusrCwS5 h7gA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ID5DZtvH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si1341211ejz.320.2020.04.16.09.00.18; Thu, 16 Apr 2020 09:00:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ID5DZtvH; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2395535AbgDPP4J (ORCPT + 99 others); Thu, 16 Apr 2020 11:56:09 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:59613 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2442746AbgDPP4D (ORCPT ); Thu, 16 Apr 2020 11:56:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587052561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nvu+MW6oZUAc4Rt+d0KHMjWiSPVqXx7NpVhFclBCSuA=; b=ID5DZtvH9sTXEpFaffj3HRg4lfpKkzt5Eql5S3WZluccUKLn/MODDhQWE18HIm5N2+o4W6 asQly0N2VAinsyOyxwMOkrAU2pfROdRYIjOTof9z9sYOK4B87LKnuPmwemuOcnsvGp8xcS DnzXGw1KxO02JWd4zJwfczZdXbSCFPY= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-124-Zc0gFejYOlal_U7CHfHI0w-1; Thu, 16 Apr 2020 11:55:59 -0400 X-MC-Unique: Zc0gFejYOlal_U7CHfHI0w-1 Received: by mail-wr1-f70.google.com with SMTP id s11so1944920wru.6 for ; Thu, 16 Apr 2020 08:55:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nvu+MW6oZUAc4Rt+d0KHMjWiSPVqXx7NpVhFclBCSuA=; b=bYdNGt/Nc8XstAMOxr+ITvh8rpAg7enoOBy5jeI3mNQbCJDe73fvh2hG05rmgp+iln 97xVPK5uNS62SbGMvJJic1LvmAEzrigp1R7fm/Inwuw95aYAR7UCvGhoxSV2sV5rPey2 E9NAPaWYU7TkXSniKUcla4/Zfk8C+/ou9RPb2m81sjDFsbj2A5FrFNNP0iH9LjbDgcOU +vkAshsAqexLA0+9MZ3VsQnNzXNcq8cUT38d9f8QyjHfT9p5BTyOzNPHJfrlVC+Ndklk /hJWeEOW1scg384s7YjKFD9DJNmm8tmXPH5JjOf4FzoMqrbadTBdcwUvLKPt//aalg42 5HEQ== X-Gm-Message-State: AGi0PuZR7wBQy9zzbiuvvNz3uhJ/Ph/A+VEDYk8CDKOKLxBDHmeYhroE INW3UHzc1fbVbTGwuE4isSkFBskZII2Bydaeq0siodl64AMnpH7mW8CnBztAQEbFYvS0F/AkB0O KULNaMS7/ONTs6KwmDyGmmXP9 X-Received: by 2002:a5d:4442:: with SMTP id x2mr18151632wrr.101.1587052558411; Thu, 16 Apr 2020 08:55:58 -0700 (PDT) X-Received: by 2002:a5d:4442:: with SMTP id x2mr18151609wrr.101.1587052558056; Thu, 16 Apr 2020 08:55:58 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:399d:3ef7:647c:b12d? ([2001:b07:6468:f312:399d:3ef7:647c:b12d]) by smtp.gmail.com with ESMTPSA id 5sm4231405wmg.34.2020.04.16.08.55.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Apr 2020 08:55:57 -0700 (PDT) Subject: Re: [PATCH v2] KVM/arm64: Support enabling dirty log gradually in small chunks To: Marc Zyngier Cc: Keqian Zhu , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, James Morse , Julien Thierry , Will Deacon , Suzuki K Poulose , Sean Christopherson , Jay Zhou , wanghaibin.wang@huawei.com References: <20200413122023.52583-1-zhukeqian1@huawei.com> <20200416160939.7e9c1621@why> From: Paolo Bonzini Message-ID: <442f288e-2934-120c-4994-5357e3e9216b@redhat.com> Date: Thu, 16 Apr 2020 17:55:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200416160939.7e9c1621@why> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/04/20 17:09, Marc Zyngier wrote: > On Wed, 15 Apr 2020 18:13:56 +0200 > Paolo Bonzini wrote: > >> On 13/04/20 14:20, Keqian Zhu wrote: >>> There is already support of enabling dirty log graually in small chunks >>> for x86 in commit 3c9bd4006bfc ("KVM: x86: enable dirty log gradually in >>> small chunks"). This adds support for arm64. >>> >>> x86 still writes protect all huge pages when DIRTY_LOG_INITIALLY_ALL_SET >>> is eanbled. However, for arm64, both huge pages and normal pages can be >>> write protected gradually by userspace. >>> >>> Under the Huawei Kunpeng 920 2.6GHz platform, I did some tests on 128G >>> Linux VMs with different page size. The memory pressure is 127G in each >>> case. The time taken of memory_global_dirty_log_start in QEMU is listed >>> below: >>> >>> Page Size Before After Optimization >>> 4K 650ms 1.8ms >>> 2M 4ms 1.8ms >>> 1G 2ms 1.8ms >>> >>> Besides the time reduction, the biggest income is that we will minimize >>> the performance side effect (because of dissloving huge pages and marking >>> memslots dirty) on guest after enabling dirty log. >>> >>> Signed-off-by: Keqian Zhu >>> --- >>> Documentation/virt/kvm/api.rst | 2 +- >>> arch/arm64/include/asm/kvm_host.h | 3 +++ >>> virt/kvm/arm/mmu.c | 12 ++++++++++-- >>> 3 files changed, 14 insertions(+), 3 deletions(-) >>> >>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst >>> index efbbe570aa9b..0017f63fa44f 100644 >>> --- a/Documentation/virt/kvm/api.rst >>> +++ b/Documentation/virt/kvm/api.rst >>> @@ -5777,7 +5777,7 @@ will be initialized to 1 when created. This also improves performance because >>> dirty logging can be enabled gradually in small chunks on the first call >>> to KVM_CLEAR_DIRTY_LOG. KVM_DIRTY_LOG_INITIALLY_SET depends on >>> KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE (it is also only available on >>> -x86 for now). >>> +x86 and arm64 for now). >>> >>> KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 was previously available under the name >>> KVM_CAP_MANUAL_DIRTY_LOG_PROTECT, but the implementation had bugs that make >>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h >>> index 32c8a675e5a4..a723f84fab83 100644 >>> --- a/arch/arm64/include/asm/kvm_host.h >>> +++ b/arch/arm64/include/asm/kvm_host.h >>> @@ -46,6 +46,9 @@ >>> #define KVM_REQ_RECORD_STEAL KVM_ARCH_REQ(3) >>> #define KVM_REQ_RELOAD_GICv4 KVM_ARCH_REQ(4) >>> >>> +#define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \ >>> + KVM_DIRTY_LOG_INITIALLY_SET) >>> + >>> DECLARE_STATIC_KEY_FALSE(userspace_irqchip_in_use); >>> >>> extern unsigned int kvm_sve_max_vl; >>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c >>> index e3b9ee268823..1077f653a611 100644 >>> --- a/virt/kvm/arm/mmu.c >>> +++ b/virt/kvm/arm/mmu.c >>> @@ -2265,8 +2265,16 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, >>> * allocated dirty_bitmap[], dirty pages will be be tracked while the >>> * memory slot is write protected. >>> */ >>> - if (change != KVM_MR_DELETE && mem->flags & KVM_MEM_LOG_DIRTY_PAGES) >>> - kvm_mmu_wp_memory_region(kvm, mem->slot); >>> + if (change != KVM_MR_DELETE && mem->flags & KVM_MEM_LOG_DIRTY_PAGES) { >>> + /* >>> + * If we're with initial-all-set, we don't need to write >>> + * protect any pages because they're all reported as dirty. >>> + * Huge pages and normal pages will be write protect gradually. >>> + */ >>> + if (!kvm_dirty_log_manual_protect_and_init_set(kvm)) { >>> + kvm_mmu_wp_memory_region(kvm, mem->slot); >>> + } >>> + } >>> } >>> >>> int kvm_arch_prepare_memory_region(struct kvm *kvm, >>> >> >> Marc, what is the status of this patch? > > I just had a look at it. Is there any urgency for merging it? No, I thought I was still replying to the v1. Paolo