If I read from my Steam Library (this has about 430GiB of data), stored on an
ext4 formatted NVMe drive like this:
find /mnt/SteamLibrary/steamapps/common -type f -exec cat {} + -type f | pv >
/dev/null
I see that it initially starts reading at 800MiB/s (6.4 Gbps) then, once my
cache fills up (as shown by buff/cache in free), the read speed drops to as low
as 6MiB/s (48 Mbps) but periodically returns to 800MiB/s as the cache gets
freed.
When the cache fills, other tasks are also affected (e.g video playback
stutters or stops). I also see high CPU usage from kswapd0 and btrfs-cleaner
(which is strange because, again, it's an ext4 filesystem that I'm reading
from) using top.
Running echo 1 > /proc/sys/vm/drop_caches immediately improves performance.
But, instead, if a run the same read command in a Memory cgroup with memory.max
set to 500M, I get a solid 800MiB/s read speed without filling up the cache or
affecting other tasks.
TL;DR simply reading files seems to be enough to cause major system-wide
performance degradation. This also applies when updating games on Steam or
moving them between Library locations.
Anyone know if this is a bug or regression in Linux 6.10? Or whether there are
any tunables or Sysctls that could improve performance without manually running
things in CGroups?
This happens on a AMD 7950X3D with 96GB of ram.
I describe the same thing on my post at:
https://www.reddit.com/r/linuxquestions/comments/1emetro/cache_filling_up_causing_drastic_performance/
It also seems that someone else has experienced something similar here:
https://www.reddit.com/r/linuxquestions/comments/1e83ltj/610_disk_caching_vs_memory_exhaustion_issues/
--
Abhinav Praveen
