linux-kernel - Re: [linus:master] [x86] 4817f70c25: stress-ng.mmapaddr.ops_per

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2212111cad3180948cf388a7e5c8689df0fdda08.camel@surriel.com>
Date: Tue, 28 Jan 2025 13:35:41 -0500
From: Rik van Riel <riel@...riel.com>
To: Qi Zheng <zhengqi.arch@...edance.com>, David Hildenbrand
 <david@...hat.com>,  Peter Zijlstra <peterz@...radead.org>
Cc: kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, 
	lkp@...el.com, linux-kernel@...r.kernel.org, Andrew Morton	
 <akpm@...ux-foundation.org>, Dave Hansen <dave.hansen@...ux.intel.com>,
 Andy Lutomirski <luto@...nel.org>, Catalin Marinas
 <catalin.marinas@....com>, David Rientjes	 <rientjes@...gle.com>, Hugh
 Dickins <hughd@...gle.com>, Jann Horn	 <jannh@...gle.com>, Lorenzo Stoakes
 <lorenzo.stoakes@...cle.com>, Matthew Wilcox <willy@...radead.org>, Mel
 Gorman <mgorman@...e.de>, Muchun Song <muchun.song@...ux.dev>,  Peter Xu
 <peterx@...hat.com>, Will Deacon <will@...nel.org>, Zach O'Keefe
 <zokeefe@...gle.com>,  Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: [linus:master] [x86] 4817f70c25: stress-ng.mmapaddr.ops_per_sec
 63.0% regression

On Wed, 2025-01-29 at 01:06 +0800, Qi Zheng wrote:
> 
> I did reproduce the performance regression using the following test
> program:
> 
> stress-ng --timeout 60 --times --verify --metrics --no-rand-seed 
> --mmapaddr 64
> 
> And its call stack is as follows:
> 
> bpftrace -e 'k:_raw_spin_unlock_irqrestore {@[kstack,comm]=count();} 
> interval:s:1 {exit();}'
> 
> @[
> _raw_spin_unlock_irqrestore+5
> free_one_page+85
> rcu_do_batch+424
> rcu_core+401
> handle_softirqs+204
> irq_exit_rcu+208

That looks like the RCU freeing somehow bypassing the
per-cpu-pages, and hitting the zone->lock at page free
time, while regular freeing usually puts pages in the
CPU-local free page cache, without the lock?

I'm not quite sure why this would be happening, though.

Maybe the RCU batches are too big for the PCPs to
hold them?

If that is the case, chances are more code paths are
hitting that issue, and we should just fix it, rather
than trying to bypass it.

Maybe the reason is more simple than that?

I have not found a place where it explicitly bypasses
the PCPs, but who knows?

-- 
All Rights Reversed.