From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-112.freemail.mail.aliyun.com (out30-112.freemail.mail.aliyun.com [115.124.30.112]) (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 3751A3AD528 for ; Wed, 10 Jun 2026 08:45:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.112 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781081116; cv=none; b=cFPYbRn8+fdigzfM+9s5ChzMoCh64GNghHasRNhzYLJGCLW34QCaMVszHfSB9xXIkG1MaHBNRMjLBV8p1domyRGjqt5nDoHENB6X95cpJ6fpkZF0Tz2Ujg15Kw0apIJmOECKrOejchECMYt9qJM1hsDF9aJP7PeHJ3rMRo1pDw0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781081116; c=relaxed/simple; bh=w2wNYJ8mvV9eEJmA3JmS5OiRjhWHlRB35VkvhfBP9Vc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ljdEnx6HplDR1g+dq52uzQeUF4XxwTymmp8VslAQ3HMoLu5RfjI8yR5fAiboUavol/yerkxFkqmU9whuT1EXw0MbeFDG6r7TtTg5Vz63hIpJ1CgfiJmFLOd6A5EfIRBrnPw3POdE8DaP9znTKtf5yJ0PGUHvvF6ti/ozEXuply0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=dXSr53MN; arc=none smtp.client-ip=115.124.30.112 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="dXSr53MN" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1781081108; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=AQEpnm1qCy04PBYgpVHbcMk1PPswJBtmq9NpRzCamVs=; b=dXSr53MNNigjatSM/En6LhBhv9V1ktdp9AqC4OxocTAg1dF7TWSyqAnVH65i1okw+Nlzmgey19L0se4UCu0XJ2L2rOfQ7PI+2wJCBCzCToysIZEycd1vG3V+sCkcljXT51fDjmUWrWSguJSUJGuBpXTPGN//SBa1IoEH3Y8DPuQ= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R841e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0X4a5o-R_1781081106; Received: from 30.74.144.110(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0X4a5o-R_1781081106 cluster:ay36) by smtp.aliyun-inc.com; Wed, 10 Jun 2026 16:45:06 +0800 Message-ID: <529db4e0-6635-4e3d-8ce5-f215ad9220cf@linux.alibaba.com> Date: Wed, 10 Jun 2026 16:45:05 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] mm/mincore: present-PTE scan cost after pte_batch_hint() batching To: Chengfeng Lin , Pedro Falcato Cc: "David Hildenbrand (Arm)" , Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Dev Jain , Ryan Roberts , Zi Yan 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> <307c2254.17b12.19eb0678f22.Coremail.chengfenglin@stu.xmu.edu.cn> From: Baolin Wang In-Reply-To: <307c2254.17b12.19eb0678f22.Coremail.chengfenglin@stu.xmu.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 6/10/26 3:20 PM, Chengfeng Lin wrote: > Hi Pedro, David, > > Thanks. I tried two newer GCC builds as well, using the same base config and > the same mm/mincore.o build target. > > The GCC 14.2 sizes were: > > v6.15 original: 0x1e8 > v6.16 original: 0x229 > v6.16 batch<=1 fastpath: 0x1d9 > v6.16 with batching removed: 0x1d9 > > I also tried GCC 15.2 from the Ubuntu 25.10 (Questing) packages, extracted > locally rather than installed system-wide: > > v6.15 original: 0x1e0 > v6.16 original: 0x221 > v6.16 batch<=1 fastpath: 0x1d1 > v6.16 with batching removed: 0x1d1 > > So GCC 14.2 and GCC 15.2 match the GCC 13.3 direction: v6.16 original still > does not collapse to the old x86 base-page shape, while the batch<=1 fastpath > and the nobatch variant produce byte-identical `mincore_pte_range()` objdump > output. Clang 18.1.3 behaves differently: all four checked variants produce > byte-identical `mincore_pte_range()` objdump output there. > > I also looked at the generated-code difference. It does not look like an > obvious extra inlining decision. With GCC 13.3, GCC 14.2 and GCC 15.2, the > original, fastpath, and nobatch builds all have the same external > call/relocation targets: > > __pte_offset_map_lock > __pmd_trans_huge_lock > memset > __cond_resched > filemap_get_incore_folio > __folio_put > swapper_spaces > > For GCC 15.2, I also saved focused optimization-dump snippets for > mincore_pte_range(). They show the same direction before final assembly: the > original build has more GCC intermediate code than the fastpath/nobatch builds > (321 optimized-dump lines and 993 RTL-expand lines, compared with 299 and > 921). > > The visible difference is the PTE-loop layout. GCC keeps the v6.16 original > `step`-based batching shape in the generated code, so the present-PTE hot path > has an extra split/jump through a common advance block. The nobatch and > batch<=1 fastpath builds produce a more compact, identical > `mincore_pte_range()` objdump. > > After Pedro's suggestion, I also tried forcing the default helper to > `__always_inline`: > > static __always_inline unsigned int pte_batch_hint(pte_t *ptep, pte_t pte) > > That did not change the result in this setup. For GCC 13.3, GCC 14.2 and > GCC 15.2, the always-inline variant has the same size and normalized > `mincore_pte_range()` objdump as v6.16 original, not the batch<=1 fastpath / > nobatch shape. > > I put the updated GCC14/GCC15 nm/objdump files, focused dump snippets, and a > short side-by-side block note here: > > https://github.com/lcf0399/linux-mm-regression-evidence-2026-05/tree/444d66373b7be32f7a06b52b3d9ced7c2c53264f/mincore-present-pte-scan/codegen > > One caveat: I have not rerun the timing part on bare metal. The timing signal > I reported is still from the QEMU direct-boot lab, so I do not want to > overstate that part. The codegen comparison above is static `mm/mincore.o` > evidence and is not QEMU-dependent. > > So the narrower result is that newer GCC did not make the codegen difference > disappear in this check. > > If there is another specific compiler/codegen detail that would be useful to > check, I can look at that. I quickly tested using your test cases (haven't reviewed your test code yet) on my x86 Xeon machine, and I didn't observe any obvious regression (tested 3 times, taking the average), and the data shows some noisy fluctuations: test cases: ./mincore_present_pte_scan no_thp_pte_scan_64m 1 metric: mincore_ns_per_1k_pages, lower is better base revert 4df65651f7075 2675 2670 I still suspect it's an issue with your QEMU test environment. I'd suggest retesting on bare metals.