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 95DFBD6B6B7 for ; Wed, 30 Oct 2024 17:19:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type: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=qr685FyY23v068XsVaeWaoBAPQAIxLMw4ZAGV7hVQrg=; b=HpTfPfXrGEdxGQM3CLUANseD/1 gNFx+0hSvUmLkZau3VQXnnDyU8lVxVCdVD4/AOALpDE3OrtQ3BicQS8ovHVUSopL69R+T2mSt8+Xt mnNp6t0qgZgCikvUyGnVMIiPvi6W1ks6APOuQc5H7MKVDrxaob3FgPfrT+66ei9uKxWSC1XQMKf9U 1PlAREohsZ/Kan45EqyEDRyXGRIEALOWJH8KwL5MBtEnN1vNoW68cVwIaXYkO+KXdQ/H52HUzmyOY /lpApkDRa1cgRhDsRK4/+nPrbdA/lt9p+ju0QxkY3COcxOxyWfcToOyCy6cIR87Umi4onGI1u/Skz W5g1zuRw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1t6CLe-00000001Fdf-3x6Z; Wed, 30 Oct 2024 17:19:10 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1t6CJy-00000001Esz-3V9U for linux-arm-kernel@lists.infradead.org; Wed, 30 Oct 2024 17:17:28 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id CA3475C4963; Wed, 30 Oct 2024 17:16:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79C97C4CECE; Wed, 30 Oct 2024 17:17:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1730308645; bh=R0lo9oWGVBLN0YXsMNqJOsG7ZWORWoqF08fNhhQfIGs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=GjEHV8hEc8KHnMa/pGa3h/xakH8Pv+dc1H9VSd+iTVBm61SjjJrHcCN/DyDuci4J7 fCrK75OPZCwDRmaicsOSD43NmHE/wS20kdldoQ3w8Mj/n2OSt/4x2gMFjgjgreIdaC vl09obqk9MRFLS10KAf2a3vTCWzCuaWT4fYCm50iKlVx0ZY6gNW8ZC3nIoN2GYJz+m yVkjjUk9zXt5aZpD+/dvF7ZeQeQUrQRLUVJBHbSgyM5w306u/hrc+u+tjyWJ9zk4sR BF85UqcAc6Eb/siuw3Cr3pz+bVoSigpGVTxCdSIklnXn/bDBkESJ8PQMSqI3CUr3UE C2Qq7aYb1Iqcw== 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 1t6CJv-008LDX-Dr; Wed, 30 Oct 2024 17:17:23 +0000 Date: Wed, 30 Oct 2024 17:17:23 +0000 Message-ID: <86wmhp1pek.wl-maz@kernel.org> From: Marc Zyngier To: Raghavendra Rao Ananta Cc: Oliver Upton , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org, syzbot Subject: Re: [PATCH v2] KVM: arm64: Get rid of userspace_irqchip_in_use In-Reply-To: References: <20241028234533.942542-1-rananta@google.com> <868qu63mdo.wl-maz@kernel.org> <865xpa3fwe.wl-maz@kernel.org> <87iktat2y8.wl-maz@kernel.org> 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/29.4 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: rananta@google.com, oliver.upton@linux.dev, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org, syzkaller@googlegroups.com 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-20241030_101726_986432_4819F5C4 X-CRM114-Status: GOOD ( 33.99 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 30 Oct 2024 16:36:19 +0000, Raghavendra Rao Ananta wrote: >=20 > On Wed, Oct 30, 2024 at 1:22=E2=80=AFAM Marc Zyngier wro= te: > > > > On Wed, 30 Oct 2024 00:16:48 +0000, > > Raghavendra Rao Ananta wrote: > > > > > > On Tue, Oct 29, 2024 at 11:47=E2=80=AFAM Marc Zyngier wrote: > > > > > > > > On Tue, 29 Oct 2024 17:06:09 +0000, > > > > Raghavendra Rao Ananta wrote: > > > > > > > > > > On Tue, Oct 29, 2024 at 9:27=E2=80=AFAM Marc Zyngier wrote: > > > > > > > > > > > > On Mon, 28 Oct 2024 23:45:33 +0000, > > > > > > Raghavendra Rao Ananta wrote: > > > > > > > > > > > > > Did you have a chance to check whether this had any negative im= pact on > > > > > > actual workloads? Since the entry/exit code is a bit of a hot s= pot, > > > > > > I'd like to make sure we're not penalising the common case (I o= nly > > > > > > wrote this patch while waiting in an airport, and didn't test i= t at > > > > > > all). > > > > > > > > > > > I ran the kvm selftests, kvm-unit-tests and booted a linux guest = to > > > > > test the change and noticed no failures. > > > > > Any specific test you want to try out? > > > > > > > > My question is not about failures (I didn't expect any), but > > > > specifically about *performance*, and whether checking the flag > > > > without a static key can lead to any performance drop on the hot pa= th. > > > > > > > > Can you please run an exit-heavy workload (such as hackbench, for > > > > example), and report any significant delta you could measure? > > > > > > Oh, I see. I ran hackbench and micro-bench from kvm-unit-tests (which > > > also causes a lot of entry/exits), on Ampere Altra with kernel at > > > v6.12-rc1, and see no significant difference in perf. > > > > Thanks for running this stuff. > > > > > timer_10ms 231040.0 = 902.0 > > > timer_10ms 234120.0 = 914.0 > > > > This seems to be the only case were we are adversely affected by this > > change. > Hmm, I'm not sure how much we want to trust this comparison. For > instance, I just ran micro-bench again a few more times and here are > the outcomes of timer_10ms for each try with the patch: >=20 > Tries total ns > avg ns > -------------------------------------------------------------------------= ---------- > 1_timer_10ms 231840.0 = 905.0 > 2_timer_10ms 234560.0 = 916.0 > 3_timer_10ms 227440.0 = 888.0 > 4_timer_10ms 236640.0 = 924.0 > 5_timer_10ms 231200.0 = 903.0 >=20 > Here's a few on the baseline: >=20 > Tries total ns > avg ns > -------------------------------------------------------------------------= ---------- > 1_timer_10ms 231080.0 = 902.0 > 2_timer_10ms 238040.0 = 929.0 > 3_timer_10ms 231680.0 = 905.0 > 4_timer_10ms 229280.0 = 895.0 > 5_timer_10ms 228520.0 = 892.0 OK, so this benchmark is all over the place, and we can't derive much from it. > > In the grand scheme of thins, that's noise. But this gives us > > a clear line of sight for the removal of the in-kernel interrupts back > > to userspace. > Sorry, I didn't follow you completely on this part. Just me moaning. The code that was gated by the static key that you just removed is used to signal interrupts from the kernel back to userspace, and I'm resisting the urge to remove it altogether now. M. --=20 Without deviation from the norm, progress is not possible.