From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794389017; b=rpLojzIflgD7IHMUsOixJjhFjEHa2A7gW6KWCwYryXzg9j2ugAM4YRjk5IhqKSRK7tP1 miQMCDd72iNRzBltRKU5+E7C+9TzKHxQgdGn2ZM1cMb+l0+brJgutg2oRx0sR4UbJqUiT aPdq2nZPpGz4Xv0lS2h+nhftsTmdaGaJRADQcZHJOHSM7lJGNNZAH1rK38Ok+SGAiNo5V N059kFKRmMS+mHnGPViLFHMJjHLh2AV/fknGT+SwckeDKjMIacPWQnzRPacMYwDt07i1U KUZS9wXVjSzTbQ9L4Zlijgzm254n22QhAY070J3XIVYxSusypGbY+SUjagLX09FFzQg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794389017; h=Received:DKIM-Signature:Received:Date:Message-ID:From:To:Cc:Subject: In-Reply-To:References:User-Agent:MIME-Version:Content-Type: X-SA-Exim-Connect-IP:X-SA-Exim-Rcpt-To:X-SA-Exim-Mail-From: X-SA-Exim-Scanned; bh=XM1myLqrMeBZLLcdumV36zM48dL30OYAz4AmPMl2HW8=; b=v6Xq1y50FShsX9LUkfaK7hRqXAFDqbS12T9UPXQAdPgsD/f8/mvvdyPIqJYZ/PYzHFPv MKSK3NfSXKw+rG3WMm8/Pzkf3fNx9hQ/vIuTmlDvIf1t2vDA6YNIbg4sPs7gE4/1eDzIK PN2JbK9la7ndH4metIFqYCheOHHbzkHLxwm/HV5EqaVnZQR8gOlTiqmPybKHbdPIypacy Z4FXQodjcAFVzN/H5yfUZ2KjFlJuuC4MxUfMeHM4Qnr98nxlfqWTvrtvnALm274PwpLGg o1wNAig36KI9SNJ6YhwHqnxS6QDnl4KWantbMCrg7NH2j9vyuz2/NfW6Rv8j3XbsqMQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=IpcFDaY6; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A47E606A32D for ; Wed, 11 Nov 2026 09:23:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=IpcFDaY6 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-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list 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 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.