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

From: intelfx
Date: Thu Aug 15 2024 - 19:17:41 EST


On 2024-08-16 at 00:21 +0200, intelfx@xxxxxxxxxxxx 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@xxxxxxxx/
> >
> > 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?

Thanks,
--
Ivan Shapovalov / intelfx /

Attachment: signature.asc
Description: This is a digitally signed message part