linux-kernel - Re: 6.10/regression/bisected - after f1d97e769152 I spotted increased execution time of the kswapd0 process and symptoms as if there is not enough memory

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20240816000231.GG25962@suse.cz>
Date: Fri, 16 Aug 2024 02:02:31 +0200
From: David Sterba <dsterba@...e.cz>
To: intelfx@...elfx.name
Cc: Filipe Manana <fdmanana@...nel.org>,
	Jannik Glückert <jannik.glueckert@...il.com>,
	andrea.gelmini@...il.com, dsterba@...e.com, josef@...icpanda.com,
	linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	mikhail.v.gavrilov@...il.com, regressions@...ts.linux.dev
Subject: Re: 6.10/regression/bisected - after f1d97e769152 I spotted
 increased execution time of the kswapd0 process and symptoms as if there is
 not enough memory

On Fri, Aug 16, 2024 at 01:17:25AM +0200, intelfx@...elfx.name wrote:
> On 2024-08-16 at 00:21 +0200, intelfx@...elfx.name wrote:
> > On 2024-08-11 at 16:33 +0100, Filipe Manana wrote:
> > > <...>
> > > This came to my attention a couple days ago in a bugzilla report here:
> > > 
> > > https://bugzilla.kernel.org/show_bug.cgi?id=219121
> > > 
> > > There's also 2 other recent threads in the mailing about it.
> > > 
> > > There's a fix there in the bugzilla, and I've just sent it to the mailing list.
> > > In case you want to try it:
> > > 
> > > https://lore.kernel.org/linux-btrfs/d85d72b968a1f7b8538c581eeb8f5baa973dfc95.1723377230.git.fdmanana@suse.com/
> > > 
> > > Thanks.
> > 
> > Hello,
> > 
> > I confirm that excessive "system" CPU usage by kswapd and btrfs-cleaner
> > kernel threads is still happening on the latest 6.10 stable with all
> > quoted patches applied, making the system close to unusable (not to
> > mention excessive power usage which crosses the line well *into*
> > "unusable" for low-power systems such as laptops).
> > 
> > With just 5 minutes of uptime on a freshly booted 6.10.5 system, the
> > cumulative CPU time of kswapd is already at 2 minutes.
> 
> As a follow-up, after 1 hour of uptime of this system the total CPU
> time of kswapd0 is exactly 30 minutes. So whatever is the theoretical
> OOM issue that the extent map shrinker is trying to solve, the solution
> in its current form is clearly unacceptable.
> 
> Can we please have it reverted on the basis of this severe regression,
> until a better solution is found?

It's not just one patch so a clean revert may not be possible, I'll see
if there's another possibility to either avoid depending on shrinker to
free the data or do a different workaround.