From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 A36DB466B73; Mon, 18 May 2026 15:36:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779118594; cv=none; b=Xh/aMY3DIlNFEnAQTlOzStq62611t6N+sjy93MAs4TIlwmjgYZ1iSuEqDniol8r1ONtaa9DbSjYTHOEZbidEcmogxU4qnm0BoVL+jummsJ/4tGvtGmufl+73v++jvKHisCbm72INkwl6mLGZKZh26z8olN3ke5Fa5vrmIhNM3uE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779118594; c=relaxed/simple; bh=h6lzYDBY+bebtEBLrGArfwg08knGWmdMX+yo4EffkBQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=HN4oLPaag/xReFdCPyMy4MwuWSxL2ixKfbSFfHLYL4P7+wSlGVzF7bGLzuzCykkMZ0XEJJHo6YJRw3H1SEfMIPyjKiMostEp5hGDOf7cyeiR/u0Nxpau4EoM8f8TxABcvELwc//hFNrk28uaDOZuKW6neRm+meQxaC3wiIVUg0g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MurWd7kO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MurWd7kO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9074C2BCB7; Mon, 18 May 2026 15:36:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1779118594; bh=h6lzYDBY+bebtEBLrGArfwg08knGWmdMX+yo4EffkBQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=MurWd7kOhGgPLFW5/2rqb2N9O8WTdfGoiylNbTnz7vlLrF1ozm89Ulor/qjtbwZa7 P5Z8v9v6oY1bIip1f0UPW05SqVwvACgjhGnO0e9mvVXwLyFerfOfRg4ca1momDYEJD /zFYNNhrRthMvj/K+fm2vFBHmkLfXQXKIqXzST4qkEBDjB2MjErHSgDwNTkG+pSdfP NlFVpGROPPbkryU/L9eoh53esGyXQ4A7PZ1QcOgCml1O4wobOSVxA2tuPP5lzMYFOl Vbg9ZtYXLdVq8JddvMSn+0F2UMrSxeYX8pw1izV4vCR/SGQEjjjA+lptqrSgb3Z45h 0PloSuxht84SA== Message-ID: Date: Mon, 18 May 2026 17:36:27 +0200 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: [REGRESSION] mm: MADV_PAGEOUT THP/no-swap refault takes ~1.7x longer on v6.19 than v6.12 To: Chengfeng Lin <23020251154299@stu.xmu.edu.cn>, Andrew Morton , linux-mm@kvack.org Cc: "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Johannes Weiner , Michal Hocko , Qi Zheng , Shakeel Butt , Chris Li , Kairui Song , linux-kernel@vger.kernel.org, regressions@lists.linux.dev, Pedro Falcato References: <662955ba.f499.19e3b2cf478.Coremail.23020251154299@stu.xmu.edu.cn> From: "David Hildenbrand (Arm)" Content-Language: en-US Autocrypt: addr=david@kernel.org; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7 /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4 jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7 LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21 zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY qIws/H2t In-Reply-To: <662955ba.f499.19e3b2cf478.Coremail.23020251154299@stu.xmu.edu.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/18/26 15:01, Chengfeng Lin wrote: > Hi, > > I would like to report a userspace-visible mprotect() performance > regression in a shared dirty PTE workload. > > The workload is intentionally narrow: > > - anonymous shared 64 MiB mapping > - prefault before protection changes > - repeatedly toggle the whole range with mprotect(PROT_READ) > - restore with mprotect(PROT_READ | PROT_WRITE) > - write-touch after the protection cycle > > This is not meant as a generic mprotect() regression report. In > particular, I am not claiming that the anon/THP mprotect paths regress. > The current signal is scoped to the shared-dirty full-range PTE toggle > path above. > > The current public evidence bundle is here: > > https://github.com/lcf0399/linux-mm-regression-evidence-2026-05/tree/e13469b/mprotect-shared-dirty-toggle > > The generated workload source used for auditing the workload semantics is > here: > > https://github.com/lcf0399/linux-mm-regression-evidence-2026-05/blob/e13469b/mprotect-shared-dirty-toggle/workload/mprotect_paths_storm.c > > The formal experiment profile is here: > > https://github.com/lcf0399/linux-mm-regression-evidence-2026-05/tree/e13469b/mprotect-shared-dirty-toggle/experiments > > The formal timing runs compare v6.12.77 and v6.19.9 with similar kernel > configuration, using QEMU direct boot. The formal performance runs were > clean timing runs with coverage disabled. Coverage was collected > separately and is not used for the timing numbers below. > > Lab environment: > > host label: lcf > host kernel: Linux 6.14.0-37-generic x86_64 > QEMU: qemu-system-x86_64 8.2.2 > container/cgroup CPU set: 0,2,4,6,8,10,12,14 > container/cgroup memory limit: 16106127360 bytes > guest memory: QEMU_MEM_MB=14336 > guest CPUs: QEMU_SMP=1/2/4 > repetitions: 9 > version order: interleaved > performance coverage_enabled: false > > Primary result, cycle_ns_per_page, lower is better: > > CPU v6.12.77 v6.19.9 old-lower-vs-new v6.19/v6.12 reliability > 1 346.8 578.1 40.0% 1.67x reliable > 2 394.7 641.7 38.5% 1.63x robust-only > 4 381.1 624.8 39.0% 1.64x partial, same direction > > The strongest current result is the 1CPU lab formal result. The 2CPU case > is same-direction but robust-only in the framework classification. The > 4CPU case is same-direction but partial because one QEMU run failed; the > summary still has 8 successful runs for that CPU count. > > The current mechanism hypothesis is local to the shared-dirty PTE path. > In v6.19, the measured hot path goes through the change_pte_range() > batching machinery: > > change_pte_range() > -> mprotect_folio_pte_batch() > -> modify_prot_start_ptes() > -> set_write_prot_commit_flush_ptes() > -> prot_commit_flush_ptes() > > For this shared-dirty workload, follow-up batch-probe attribution showed > nr_ptes=1 in the measured path. The hypothesis is that the extra folio > lookup, batch-size query, helper dispatch, and commit machinery are paid > per 4 KiB PTE without effective batch-size amortization in this workload. > This is mechanism interpretation, not a completed culprit-commit bisect. > > I have not bisected the exact culprit commit yet. Separate release-level > sanity checks showed v6.18.19 already in the slow range, so the current > best reporting range is: > > #regzbot introduced: v6.12..v6.18 > > Please let me know if a standalone reproducer, a narrower bisect, or > additional raw logs would be more useful. Pedro recently optimized this: https://lore.kernel.org/all/20260402141628.3367596-1-pfalcato@suse.de/ Maybe that fixes most of the regression for you? -- Cheers, David