You are not logged in.

#1 2024-07-23 19:45:38

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)

Offline

#2 2024-07-23 19:57:16

loqs
Member
Registered: 2014-03-06
Posts: 18,087

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.

Offline

#3 2024-07-23 22:15:12

gromit
Package Maintainer (PM)
From: Germany
Registered: 2024-02-10
Posts: 710
Website

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

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

Offline

#4 2024-07-23 22:32:28

Sanya_M
Member
Registered: 2014-01-04
Posts: 4

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

gromit wrote:

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

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

loqs wrote:

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.

Offline

#5 2024-07-23 22:37:56

gromit
Package Maintainer (PM)
From: Germany
Registered: 2024-02-10
Posts: 710
Website

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

Offline

#6 2024-07-23 23:12:44

loqs
Member
Registered: 2014-03-06
Posts: 18,087

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

Offline

#7 2024-07-31 17:52:02

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.

Offline

#8 2024-07-31 21:19:10

gromit
Package Maintainer (PM)
From: Germany
Registered: 2024-02-10
Posts: 710
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

Offline

#9 2024-08-05 07:59:49

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)

Offline

Board footer

Powered by FluxBB