From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B12D4606A324 for ; Wed, 11 Nov 2026 09:23:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=zIc/Zna8; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=IpcFDaY6 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-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=XM1myLqrMeBZLLcdumV36zM48dL30OYAz4AmPMl2HW8=; b=zIc/Zna8I8IqKm8GeRIMRHcEnj xWvE9Tyk1bIZUGo/JBF2MrgYoqpS2XqyQsf6xfqJbQSVvn+BP0CdhjDAQFeq/IXMHnzCd2aHq7VWe JLeDfy03ZI/EzZgmgs/yGPvzAqkjGq24Tal087/iT/sJDnPB7FbWVtBkxUtnWG89DuPVSIIf6imA5 qpz/eguNCDh9ZILE+cjph8IUy/UeafHwR61HHFodquoQg+qnUd56hH90lTDUYUrCM3ArC8Cb6hZE5 7X3+5NkLvCKtVtVl+Vl3K20f8+AeLV7Ebf3r5heNtaLr7aPgXVtBlCcQ5YyGl+Iefb5Pz0p3MbcFv LeXU9Bcg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xR4YN-000000069YY-1spP; Wed, 11 Nov 2026 09:23:39 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xR4YL-000000069YR-3XcR for linux-arm-kernel@lists.infradead.org; Wed, 11 Nov 2026 09:23:37 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 349974706D; Wed, 11 Nov 2026 09:23:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14E741F00A0A; Wed, 11 Nov 2026 09:23:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794389017; bh=XM1myLqrMeBZLLcdumV36zM48dL30OYAz4AmPMl2HW8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=IpcFDaY6pk4tutRQHhQrsaGjHFwSQqncbI6g7nPRWuSO06PWxftRJfP/faYKmBZau ifYx6DE25f0iNWDgYjibx6h205e+Tl08Hx+JnwMCTSB36GZHvbhfNkKRfY4HTqKJtN ufS3n2hGpJGR11fikgdqgMdXRRP8Bve/gvhRia9EoLWegycExBZRtCWYe40ceaCEix +H0EP50KzojeCgjXorj5QDT4k1V2x2BRlBw0UxJHsUe2JoZq3DW+BP53r0X3Z7LxgQ uEtvb4sZS2559Bhplcxs6psnAWFR2P7QNRtdFru+HZoLAJBxJiF7rKk6cs4ZxPeI6f 3hPdIOJ7TKpeA== 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.98.2) (envelope-from ) id 1xR4YI-0000000ED4P-2UhZ; Wed, 11 Nov 2026 09:23:34 +0000 Date: Wed, 11 Nov 2026 09:23:34 +0000 Message-ID: <86pkwb202x.wl-maz@kernel.org> From: Marc Zyngier To: Vincent Donnefort Cc: oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, kernel-team@android.com, fuad.tabba@linux.dev, ljs@kernel.org, ryan.roberts@arm.com Subject: Re: [PATCH v1] KVM: arm64: Fast path transparent_hugepage_adjust() for non-PMD folios In-Reply-To: References: <20261102211900.504192-1-vdonnefort@google.com> <867biu2ujs.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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Archived-By: 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: vdonnefort@google.com, oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, kernel-team@android.com, fuad.tabba@linux.dev, ljs@kernel.org, ryan.roberts@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On Tue, 03 Nov 2026 14:26:33 +0000, Vincent Donnefort wrote: > > On Tue, Nov 03, 2026 at 08:22:47AM +0000, Marc Zyngier wrote: > > On Mon, 02 Nov 2026 21:19:00 +0000, > > Vincent Donnefort wrote: > > > > > > transparent_hugepage_adjust() must walk the userspace stage-1 to detect > > > if a PMD-level mapping is installed. If it is, then a stage-2 block > > > mapping can be installed. Even though this stage-1 walk is most likely > > > cache hot (in most cases, the mapping has just been installed), walking > > > a page-table is still costly. This walks accounts for ~5% of the > > > user_mem_abort() execution time on an Apple M2 big core. This makes a > > > fast path interesting. > > > > This raises a few questions: > > > > - Isn't this a "fast fail" rather than a fast path? You don't make the > > S1 walk faster, but you instead avoid cases where it would have > > returned an level-3 size. > > > > If anything, you make transparent_hugepage_adjust() slower for the > > case that succeeds. I don't think this invalidates the approach, but > > it feels that the commit message is just wrong. > > Yes, "fast fail" would be a far better description. > > > > > - How do you measure this? 5% feels like a huge amount for something > > that should be 3 loads. Isn't this more an indication that the page > > table walker is overly complicated because it was designed for > > something else? In any case, It'd be good to verify your findings, > > so please provide a minimal reproducer. > > I have booted with qemu a L1 guest. Pinned to the biggest CPUs of the Mac M2 and > set the performance governor. > > Then in the L1 guest, I disabled completely THPs and enabled the tracing > function_graph to measure user_mem_abort() and get_user_mapping_size(), before > booting a L2 guest with a single vCPU. Oh crap, this is *nested*! No wonder things take ages, as you end-up going via S2 (and any miss in a TLB is pretty taxing). This really should be captured in the commit message... What is the impact on a non-NV setup? > That gave me something like ... > > 0) | user_mem_abort() { > 0) 0.208 us | get_user_mapping_size(); > 0) 5.958 us | } > > I have skipped the outliers (the function_graph prefix them with '+', '$' ...) > which I believe are most likely related to interrupts. > > Then for each pair, I got the percentage get_user_mapping_size() represents in > the user_mem_abort() execution time. > > Now looking again at the results I have, I realised I gave the mean (5%) but > perhaps the median which is 2.7% is a better representation of the overall > improvement and is slightly less impressive. Yeah, but still. Please respin this with an amended commit message, and we'll see how we route this. Thanks, M. -- Without deviation from the norm, progress is not possible.