Arch Linux

Sanya_M

Member

Registered: 2014-01-04

Posts: 4

Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

After I installed 6.10 kernel update, I've noticed that the GNOME Shell sometimes becomes unresponsive, almost freezes.

I found out that it's caused by mlocate's updatedb process. Running

systemctl start updatedb.service

reproduces the problem.

However, it doesn't happen with kernel 6.9.10. I can watch youtube while updatedb is running, and won't notice it. Also, updatedb is about 3x slower on 6.10.

On 6.10:

Jul 23 22:17:30 amezin-laptop.home.arpa systemd[1]: updatedb.service: Consumed 8min 7.865s CPU time, 9.1G memory peak.
Jul 23 22:17:30 amezin-laptop.home.arpa systemd[1]: Finished Update locate database.
Jul 23 22:17:30 amezin-laptop.home.arpa systemd[1]: updatedb.service: Deactivated successfully.
Jul 23 22:08:03 amezin-laptop.home.arpa systemd[1]: Starting Update locate database...

On 6.9.10:

Jul 23 21:55:46 amezin-laptop.home.arpa systemd[1]: updatedb.service: Consumed 57.781s CPU time, 5.3G memory peak.
Jul 23 21:55:46 amezin-laptop.home.arpa systemd[1]: Finished Update locate database.
Jul 23 21:55:46 amezin-laptop.home.arpa systemd[1]: updatedb.service: Deactivated successfully.
Jul 23 21:53:18 amezin-laptop.home.arpa systemd[1]: Starting Update locate database...

I rolled the update back and forth, and repeated the test multiple times. 6.10 always has issues, 6.9.10 always ok.

It seems that increased memory use could be the cause:

[  328.880960] systemd-journald[768]: Under memory pressure, flushing caches.
[  345.093946] systemd-journald[768]: Under memory pressure, flushing caches.

It's a laptop with 16 gb ram and an iGPU, showing only 13.3 gb as actually usable - close to 9.1G memory peak.

Does anyone else experience a similar issue?

Last edited by Sanya_M (2024-07-23 20:25:30)

loqs

Member

Registered: 2014-03-06

Posts: 17,861

Re: Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

Please consider bisecting linux between 6.9 and 6.10 to determine the causal commit.

gromit

Package Maintainer (PM)

From: Germany

Registered: 2024-02-10

Posts: 380

Website

Re: Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

Which filesystem are you using? Are you on BTRFS by chance?

Sanya_M

Member

Registered: 2014-01-04

Posts: 4

Re: Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

Which filesystem are you using? Are you on BTRFS by chance?

Yes, btrfs, on top of a luks partition to make things more complicated.

Please consider bisecting linux between 6.9 and 6.10 to determine the causal commit.

Before wasting time on bisect I just wanna make sure it's not a problem already solved by someone.

gromit

Package Maintainer (PM)

From: Germany

Registered: 2024-02-10

Posts: 380

Website

Re: Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

It could be this one https://lore.kernel.org/all/CABXGCsMmmb … gmail.com/

loqs

Member

Registered: 2014-03-06

Posts: 17,861

Re: Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

It could be this one https://lore.kernel.org/all/CABXGCsMmmb … gmail.com/

Was that issue fixed by https://git.kernel.org/pub/scm/linux/ke … 542928ec03?

KenMacD

Member

Registered: 2014-01-06

Posts: 20

Re: Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

As a heads-up I'm seeing similar issues with btrfs + 6.10.2 + restic. Same high kswapd0 usage as that thread mentions, so I suspect it's not entirely solved.

gromit

Package Maintainer (PM)

From: Germany

Registered: 2024-02-10

Posts: 380

Website

Re: Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

There is someone currently debugging this on the bugtracker I think: https://gitlab.archlinux.org/archlinux/ … /issues/70

primeheretic

Member

Registered: 2012-04-25

Posts: 7

Re: Kernel 6.10 regression: mlocate/updatedb 3x slower, unresponsive shell

FWIW I'm experiencing what I think is the same issue, also using BTRFS.  You'll see updatedb and other processes like firefox, chromium eating cpu.

As a temp fix

echo 1 > /proc/sys/vm/drop_caches

seems to resolve it, till it returns.  Keeping an eye on the above bug tracking.

Last edited by primeheretic (2024-08-05 08:00:20)