From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29A32346A14 for ; Tue, 9 Jun 2026 21:12:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781039559; cv=none; b=hx9AmombYqaKGlwkuVC0utF9+kxKUnM+eOKyqSZscMLDVz1jnURuakEDHsA1YF5TObdFTW7GeMBwiJWpV9tuK0hUEr/ZDyv8z76OV8npyY4XTshTkM62qNAd9Y79Z+uo0A8Li7BJQO/NXYdyNkF3yGF6tRWjlS8pdwUVYrge408= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781039559; c=relaxed/simple; bh=AYpHQ9zRL+ydF28IimVCKcav35a3ADugUxJB+FYzwlM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=L+6gs2M3Wo6SvwMcdaCpIQLZyWN85BoZ2lSI2sM45Cl/N/PlLB3tvPAPZHEaGg3YZhF5yM8y/KacNAWgaCvuv9dq+I60QdARKsp0lNkpMCr8HXKG/Yi178pmdnlcMGF9TchGRW71TN8IAX5k2uRNXPanOF/ht6b26/S/Wz/3cQI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de; spf=pass smtp.mailfrom=suse.de; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=uBE4ogiS; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=zmTSAtbU; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b=uBE4ogiS; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b=zmTSAtbU; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="uBE4ogiS"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="zmTSAtbU"; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="uBE4ogiS"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="zmTSAtbU" Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2E6946AC18; Tue, 9 Jun 2026 21:12:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1781039556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FnlPumnoP1QUrRfMOMDX/uOPlORxRhIf1SgZh5OHpg8=; b=uBE4ogiSo6YE0QfRRL8um+PL/x62b3GSQrz/YeaqqV3QuXgw9zhlycGbetDodUe1HKhJPS VHigpgrTuqSLgOSw7bPC1M21SFQNdqObOvQsFKc0PXerveiwPbK1HParc2WFW1qTZ4HeoV lskFl8WV3WIyWOOSqxzbvuuS1DAjrxQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1781039556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FnlPumnoP1QUrRfMOMDX/uOPlORxRhIf1SgZh5OHpg8=; b=zmTSAtbUzRhxaUBZ/Ax2qkGNeJtY3RVllL3tAEjcYcqwDz/+/tBJimg+jzp0lb0zUeg6Xo nt1ve/6yjNFqecCA== Authentication-Results: smtp-out1.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=uBE4ogiS; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=zmTSAtbU DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1781039556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FnlPumnoP1QUrRfMOMDX/uOPlORxRhIf1SgZh5OHpg8=; b=uBE4ogiSo6YE0QfRRL8um+PL/x62b3GSQrz/YeaqqV3QuXgw9zhlycGbetDodUe1HKhJPS VHigpgrTuqSLgOSw7bPC1M21SFQNdqObOvQsFKc0PXerveiwPbK1HParc2WFW1qTZ4HeoV lskFl8WV3WIyWOOSqxzbvuuS1DAjrxQ= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1781039556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FnlPumnoP1QUrRfMOMDX/uOPlORxRhIf1SgZh5OHpg8=; b=zmTSAtbUzRhxaUBZ/Ax2qkGNeJtY3RVllL3tAEjcYcqwDz/+/tBJimg+jzp0lb0zUeg6Xo nt1ve/6yjNFqecCA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 28EDA779A7; Tue, 9 Jun 2026 21:12:35 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id dHWeBsOBKGrlWAAAD6G6ig (envelope-from ); Tue, 09 Jun 2026 21:12:35 +0000 Date: Tue, 9 Jun 2026 22:12:33 +0100 From: Pedro Falcato To: "David Hildenbrand (Arm)" Cc: Chengfeng Lin , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Baolin Wang , Barry Song , Dev Jain , Ryan Roberts , Zi Yan Subject: Re: [RFC] mm/mincore: present-PTE scan cost after pte_batch_hint() batching Message-ID: References: <5fb8bead.17483.19eab4626f5.Coremail.chengfenglin@stu.xmu.edu.cn> <74cdec57-67aa-4ae3-a416-e39846049ab1@kernel.org> <2780f0f6.176fd.19eacba49bb.Coremail.chengfenglin@stu.xmu.edu.cn> <106e71e4-975c-4337-aaff-a00628827477@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <106e71e4-975c-4337-aaff-a00628827477@kernel.org> X-Rspamd-Action: no action X-Rspamd-Queue-Id: 2E6946AC18 X-Spam-Flag: NO X-Spam-Score: -4.51 X-Spam-Level: X-Spamd-Result: default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; ARC_NA(0.00)[]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; RCPT_COUNT_TWELVE(0.00)[14]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RCVD_TLS_ALL(0.00)[]; FUZZY_RATELIMITED(0.00)[rspamd.com]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[pedro-suse.lan:mid,suse.de:dkim,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; DKIM_TRACE(0.00)[suse.de:+] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org On Tue, Jun 09, 2026 at 04:27:50PM +0200, David Hildenbrand (Arm) wrote: > On 6/9/26 16:12, Chengfeng Lin wrote: > > Hi David, > > Hi, > > > Thanks, and sorry for the confusing wording. The plain statement is: I > > observed a performance difference in a narrow x86/QEMU synthetic mincore() > > case, and after your comment I checked whether this is really a codegen issue. > > > > The wording in my first mail was too abstract. What I was trying to say is > > only that the benchmark focuses on one specific case: > > > > private anonymous memory > > MADV_NOHUGEPAGE > > faulted/resident base pages > > repeated mincore() over the range > > > > so the measured path should mostly be the present-PTE scan in > > mincore_pte_range(). I agree that the 8/16 CPU rows are not very useful for > > this path; please treat them as extra context only. The useful data is the > > single-threaded / low-CPU v6.15 -> v6.16 A/B and the patched variants. > > > > The compiler used for the lab kernels was: > > > > gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0 > > Okay, GCC 13 was released 3 years ago. > > > GNU ld (GNU Binutils for Ubuntu) 2.42 > > > > Your point about x86 pte_batch_hint() is exactly the right thing to check. > > Since pte_batch_hint() returns 1 on x86, I agree that the expectation would be > > for the compiler to optimize the batching logic back down to something very > > close to the old base-page path. > > > > I checked the generated mincore_pte_range() code with the same GCC/config setup. > > The function sizes from nm are: > > > > v6.15 original: 0x1fb > > v6.16 original: 0x245 > > v6.16 batch<=1 fastpath: 0x1ec > > v6.16 with batching removed: 0x1ec > > > > So, with GCC 13.3, the v6.16 original build does not look optimized back to the > > old x86 base-page shape. The v6.16 batch<=1 fastpath and the v6.16 nobatch > > variant produce the same mincore_pte_range() objdump output in my build. > > > > I also checked Clang 18.1.3 as a cross-check. With Clang, v6.15 original, > > v6.16 original, v6.16 batch<=1 fastpath and v6.16 nobatch all produce the same > > mincore_pte_range() size, 0x1f9, and the objdump output is byte-identical. > > > > So your expectation does hold with Clang, but not with the GCC 13.3 build I used > > for the original lab runs. This does not prove a compiler bug, and it means my > > original report should be narrowed: it is not a generic x86 mincore() > > regression claim. In this check, GCC 13.3 generates a different > > mincore_pte_range() shape for v6.16 original, while Clang 18.1.3 generates > > byte-identical output for all checked variants. The timing signal I reported > > came from the GCC-built QEMU lab kernels. > > It's probably a good idea to > > 1) Try with newer GCC > > 2) Take a look at the actual difference in the generated code > > Is it some inlining decisions? E.g., if the function is larger, other code is > likely to get inlined? > > The function is not particularly large, so it's a bit unexpected. > FWIW, I don't see anything costly in the linked commit. The compiler /should/ be able to inline and constant fold everything (for near byte-identical output). Though I vaguely recall that GCC uses pseudo-metrics (probably not LOC?) when figuring out what to inline, not necessarily something that maps to machine instructions directly. So I am curious as to whether this is a compiler issue as well. Or if this particular build just happens to hit the issue due to some random limit. This could be worth a test, however: diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index cdd68ed3ae1a..0e0ac7138d8c 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -373,7 +373,7 @@ static inline void lazy_mmu_mode_resume(void) {} * * May be overridden by the architecture, else pte_batch_hint is always 1. */ -static inline unsigned int pte_batch_hint(pte_t *ptep, pte_t pte) +static __always_inline unsigned int pte_batch_hint(pte_t *ptep, pte_t pte) { return 1; } -- Pedro