From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0BB7D7E for ; Mon, 4 Sep 2023 09:57:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F895C433C8; Mon, 4 Sep 2023 09:57:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693821448; bh=KCgrMSpReKkomAvjrgAyI+M74AruhN3j2aeC3Jx7Y+g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MpQRi+AyB0glohPHvUIs5L0PJBy56ywLS/W3DOBlGZczOTro6uLRuZXW19unGTcYD Tp4cFFCkpNKYDGLzLltFyVr2zlrSidWZKX6Jqo5OA9+0G9uNbKE8HTBm7V4QF+XZAZ FsQmWEAin7RKf/Se/pjD6v3Dj17PeDCTchxVwQaYjPJE6j4y+W+K1oM8xFi6VZQjT9 Qg4mHRo6TW7ULwrjc7A5lLZ+H3Q2BIdodMI++Tv30dspoBcLn03g9iKl+gQsYoPU2p Iju5S1r3VUsVfsYFQY/8rv22rkS4a4ekB77raDYFciJl30Rh3Ca2KZOEHJ1umIhBvF w+VvKYzOmRa4Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qd6Kj-00ANAe-VB; Mon, 04 Sep 2023 10:57:26 +0100 Date: Mon, 04 Sep 2023 10:57:24 +0100 Message-ID: <86o7iidzwb.wl-maz@kernel.org> From: Marc Zyngier To: Xu Zhao Cc: oliver.upton@linux.dev, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [RFC v2] KVM: arm/arm64: optimize vSGI injection performance In-Reply-To: <20230825015811.5292-1-zhaoxu.35@bytedance.com> References: <20230825015811.5292-1-zhaoxu.35@bytedance.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: zhaoxu.35@bytedance.com, oliver.upton@linux.dev, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Fri, 25 Aug 2023 02:58:11 +0100, Xu Zhao wrote: > > In a VM with more than 16 vCPUs (with multiple aff0 groups), if the target > vCPU of a vSGI exceeds 16th vCPU, kvm needs to iterate from vCPU0 until > the target vCPU is found. However, affinity routing information is provided > by the ICC_SGI* register, which allows kvm to bypass other aff0 groups, > iterating only on the aff0 group that the target vCPU located. It reduces > the maximum iteration times from the total number of vCPUs to 16, or even > 8 times. > > This patch aims to optimize the vSGI injecting performance of injecting > target exceeds 16th vCPU in vm with more than 16 vCPUs. The problem is that you optimise it for the default case, and break it for *everything* else. [...] > The performance of VM witch 32 cores improvement can be observed. When > injecting SGI into the first vCPU of the first aff0 group, the performance > remains the same as before (because the number of iteration is also 1), > but there is an improvement in performance when injecting interrupts into > the last vCPU. When injecting vSGI into the first and last vCPU of the > second aff0 group, the performance improvement is significant because > compared to the original algorithm, it skipped iterates the first aff0 > group. > > BTW, performance improvement can also be observed by microbench in > kvm-unit-test with little modification :add 32 cores initialization, > then change IPI target CPU in function ipi_exec. > > The more vcpu a VM has, the greater the performance improvement of injecting > vSGI into the vCPU in the last aff0 group. > > Signed-off-by: Xu Zhao > --- > arch/arm64/kvm/vgic/vgic-mmio-v3.c | 152 ++++++++++++++--------------- > include/linux/kvm_host.h | 5 + > 2 files changed, 78 insertions(+), 79 deletions(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > index 188d2187eede..af8f2d6b18c3 100644 > --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c > +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > @@ -1013,44 +1013,64 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr) > > return 0; > } > + > /* > - * Compare a given affinity (level 1-3 and a level 0 mask, from the SGI > - * generation register ICC_SGI1R_EL1) with a given VCPU. > - * If the VCPU's MPIDR matches, return the level0 affinity, otherwise > - * return -1. > + * Get affinity routing index from ICC_SGI_* register > + * format: > + * aff3 aff2 aff1 aff0 > + * |- 8 bits -|- 8 bits -|- 8 bits -|- 4 bits -| > */ > -static int match_mpidr(u64 sgi_aff, u16 sgi_cpu_mask, struct kvm_vcpu *vcpu) > +static unsigned long sgi_to_affinity(unsigned long reg) > { > - unsigned long affinity; > - int level0; > + u64 aff; > > - /* > - * Split the current VCPU's MPIDR into affinity level 0 and the > - * rest as this is what we have to compare against. > - */ > - affinity = kvm_vcpu_get_mpidr_aff(vcpu); > - level0 = MPIDR_AFFINITY_LEVEL(affinity, 0); > - affinity &= ~MPIDR_LEVEL_MASK; > + /* aff3 - aff1 */ > + aff = (((reg) & ICC_SGI1R_AFFINITY_3_MASK) >> ICC_SGI1R_AFFINITY_3_SHIFT) << 16 | > + (((reg) & ICC_SGI1R_AFFINITY_2_MASK) >> ICC_SGI1R_AFFINITY_2_SHIFT) << 8 | > + (((reg) & ICC_SGI1R_AFFINITY_1_MASK) >> ICC_SGI1R_AFFINITY_1_SHIFT); Here, you assume that you can directly map a vcpu index to an affinity. It would be awesome if that was the case. However, this is only valid at reset time, and userspace is perfectly allowed to change this mapping by writing to the vcpu's MPIDR_EL1. So this won't work at all if userspace wants to set its own specific CPU numbering. M. -- Without deviation from the norm, progress is not possible. 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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 46AFAC83F3F for ; Mon, 4 Sep 2023 09:58:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=6IrkKflbW+W44IldNjeRZ91YpZEqpOhwHj1b8/xeFUA=; b=ujSXyyjM+xOCLj 9fOMR96vBAsrv8PQW5QemvXwO/giPVljPZ+6UhlGogZ+ifo/x5tXpjal1oPuEk8ln0ZJsHa9t+KqA B9wd3B9WQHM3S3+lBMFShzPJLVqgrf3qKd2ZxMLilLztcntZfoVCEg5/Nl5OaavdRN4akJLpGA3BS 1pA+eo7UZIXcqygET6gznK0ot6fpE4j5kovMVM0WH6EhmbugBBHzO4504C7QaphG2DIVLmEH//4Ho +8ymfg8l+PMEuT2DSSuLLAx6ACKDT8UCTLMSBPcElH71vtZ07a9SUV6sm+BCDrMgCZ5Q/Hk9VM5ZF V4aFEcFiCSzW9Nmyh4Yw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qd6Kr-003jhj-2t; Mon, 04 Sep 2023 09:57:33 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qd6Kp-003jfw-1F for linux-arm-kernel@lists.infradead.org; Mon, 04 Sep 2023 09:57:33 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id A907CB80DE0; Mon, 4 Sep 2023 09:57:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F895C433C8; Mon, 4 Sep 2023 09:57:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1693821448; bh=KCgrMSpReKkomAvjrgAyI+M74AruhN3j2aeC3Jx7Y+g=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=MpQRi+AyB0glohPHvUIs5L0PJBy56ywLS/W3DOBlGZczOTro6uLRuZXW19unGTcYD Tp4cFFCkpNKYDGLzLltFyVr2zlrSidWZKX6Jqo5OA9+0G9uNbKE8HTBm7V4QF+XZAZ FsQmWEAin7RKf/Se/pjD6v3Dj17PeDCTchxVwQaYjPJE6j4y+W+K1oM8xFi6VZQjT9 Qg4mHRo6TW7ULwrjc7A5lLZ+H3Q2BIdodMI++Tv30dspoBcLn03g9iKl+gQsYoPU2p Iju5S1r3VUsVfsYFQY/8rv22rkS4a4ekB77raDYFciJl30Rh3Ca2KZOEHJ1umIhBvF w+VvKYzOmRa4Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1qd6Kj-00ANAe-VB; Mon, 04 Sep 2023 10:57:26 +0100 Date: Mon, 04 Sep 2023 10:57:24 +0100 Message-ID: <86o7iidzwb.wl-maz@kernel.org> From: Marc Zyngier To: Xu Zhao Cc: oliver.upton@linux.dev, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [RFC v2] KVM: arm/arm64: optimize vSGI injection performance In-Reply-To: <20230825015811.5292-1-zhaoxu.35@bytedance.com> References: <20230825015811.5292-1-zhaoxu.35@bytedance.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: zhaoxu.35@bytedance.com, oliver.upton@linux.dev, james.morse@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230904_025731_698590_69217E4D X-CRM114-Status: GOOD ( 33.87 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 25 Aug 2023 02:58:11 +0100, Xu Zhao wrote: > > In a VM with more than 16 vCPUs (with multiple aff0 groups), if the target > vCPU of a vSGI exceeds 16th vCPU, kvm needs to iterate from vCPU0 until > the target vCPU is found. However, affinity routing information is provided > by the ICC_SGI* register, which allows kvm to bypass other aff0 groups, > iterating only on the aff0 group that the target vCPU located. It reduces > the maximum iteration times from the total number of vCPUs to 16, or even > 8 times. > > This patch aims to optimize the vSGI injecting performance of injecting > target exceeds 16th vCPU in vm with more than 16 vCPUs. The problem is that you optimise it for the default case, and break it for *everything* else. [...] > The performance of VM witch 32 cores improvement can be observed. When > injecting SGI into the first vCPU of the first aff0 group, the performance > remains the same as before (because the number of iteration is also 1), > but there is an improvement in performance when injecting interrupts into > the last vCPU. When injecting vSGI into the first and last vCPU of the > second aff0 group, the performance improvement is significant because > compared to the original algorithm, it skipped iterates the first aff0 > group. > > BTW, performance improvement can also be observed by microbench in > kvm-unit-test with little modification :add 32 cores initialization, > then change IPI target CPU in function ipi_exec. > > The more vcpu a VM has, the greater the performance improvement of injecting > vSGI into the vCPU in the last aff0 group. > > Signed-off-by: Xu Zhao > --- > arch/arm64/kvm/vgic/vgic-mmio-v3.c | 152 ++++++++++++++--------------- > include/linux/kvm_host.h | 5 + > 2 files changed, 78 insertions(+), 79 deletions(-) > > diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > index 188d2187eede..af8f2d6b18c3 100644 > --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c > +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c > @@ -1013,44 +1013,64 @@ int vgic_v3_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr) > > return 0; > } > + > /* > - * Compare a given affinity (level 1-3 and a level 0 mask, from the SGI > - * generation register ICC_SGI1R_EL1) with a given VCPU. > - * If the VCPU's MPIDR matches, return the level0 affinity, otherwise > - * return -1. > + * Get affinity routing index from ICC_SGI_* register > + * format: > + * aff3 aff2 aff1 aff0 > + * |- 8 bits -|- 8 bits -|- 8 bits -|- 4 bits -| > */ > -static int match_mpidr(u64 sgi_aff, u16 sgi_cpu_mask, struct kvm_vcpu *vcpu) > +static unsigned long sgi_to_affinity(unsigned long reg) > { > - unsigned long affinity; > - int level0; > + u64 aff; > > - /* > - * Split the current VCPU's MPIDR into affinity level 0 and the > - * rest as this is what we have to compare against. > - */ > - affinity = kvm_vcpu_get_mpidr_aff(vcpu); > - level0 = MPIDR_AFFINITY_LEVEL(affinity, 0); > - affinity &= ~MPIDR_LEVEL_MASK; > + /* aff3 - aff1 */ > + aff = (((reg) & ICC_SGI1R_AFFINITY_3_MASK) >> ICC_SGI1R_AFFINITY_3_SHIFT) << 16 | > + (((reg) & ICC_SGI1R_AFFINITY_2_MASK) >> ICC_SGI1R_AFFINITY_2_SHIFT) << 8 | > + (((reg) & ICC_SGI1R_AFFINITY_1_MASK) >> ICC_SGI1R_AFFINITY_1_SHIFT); Here, you assume that you can directly map a vcpu index to an affinity. It would be awesome if that was the case. However, this is only valid at reset time, and userspace is perfectly allowed to change this mapping by writing to the vcpu's MPIDR_EL1. So this won't work at all if userspace wants to set its own specific CPU numbering. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel