I’ve seen this behaviour on two other machines running Tumbleweed as well. One i5-8265U with 8GB + NVME and a very old Core2 Duo with just 2 GB of RAM + SSD.
I observe the follwoing:
When copying large files, the buffer / cache keeps expanding until the machine runs out of pyhsical ram and starts swapping. This comes with the expected speed penalty / lack of responsiveness, iostat shows above 90% iowait for kswapd0.
This problem goes away when disabling all swap space, transfer speed is high, the system is responsive.
I have a fundamental problem with this. I don’t see the point of increasing buffers / cache so much that the system starts swapping, just for copying a large file (say VM image or the likes).
I could be wrong, but I don’t think I’ve observed this behaviour in recent years. It doesn’t make any sense to me.
I wrote about zypper to suggest I might be able to try to closely replicate your observation, but my system mentioned has no filesystem on it anywhere near as big as 40GB, much less any file that size.
Currently I run tests on my old laptop (2G RAM) like so:
dd if=/dev/sda of=/dev/null status=progress
This performs as expected for such an old machine (1.5Gbs SATA-I). At some point it starts hitting SWAP and speeds go down to about 50%, same device 2x the IO.
Swap space usage is very low, just a few 10s of MB, but the activity is constant. I run these tests with no other applications, except a terminal on X.
I really don’t see what should be swapped out here. I’ve played with vm.swappiness, but that just offsets the point at which swapping starts.
I think this behaviour is pathological, nothing should be swapped out to increase buffers / cache, ever.
The HW in my main laptop is similar to your inxi results.
Same behavior here: Started dd if=/dev/sdc of=/dev/null bs=4M with no swap being active. Everything was fine until I turned swap on. The machine would freeze immediately. Swapoff runs for minutes until finally succeeding. I think it is a kernel bug.
What do you do with the Core2Duo PC besides copy large files? Most old Core2Duos with only 2G RAM have 4 RAM slots with 2 unused. You could improve behavior if necessary for more extensive activity by adding a pair of 2G sticks rather cheaply. Maybe you don’t need swap enabled. You could run swapoff prior to copy, then swapon after. Or, just leave the swap partition disabled, and let the OS use a swap file when it thinks it needs swap. The bug report should get attention soon after the new year if not before.
That laptop has been demoted to a YouTube & Netflix viewer since some time ago something bad has happened to graphics performance of i915 + GM945.
I use it to test this issue, as it is most apparent on it, but not limited to it. My i7 laptop shows similar behaviour when copying VM images, they’re just a whole lot larger.
It is still not acceptable that copying stuff can slow GUI response to thick molasses.
The old laptop has 2 SO-DIMM slots, the BIOS (recent version) only supports up to 3GB of RAM, I tried upgrading, it doesn’t work. The device is one step away from trashing it, but it still “works” and the DVD drive is region free.
I’m quite annoyed that I have to “suffer” from this on Linux, wheres on W10 (office PC) nothing of that sort happens - similar CPU, same amount of RAM.
I used to run Leap 15.0 on it and it was snappy, GUI was always fast, with 15.1 something changed. I see the same on about 13 old PCs at work. Ran 15.0, switched to TW and BOOM, same graphics badness on recent Debian, Ubuntu …
I have 2 i945Gs (desktops, not GM945 laptops). Both run P4s (single core) @3.0Ghz. They’ve always seemed like toads compared to other Intel hardware, so I never noticed any change in later distro releases.
There has been an interesting discussion on the LKML (Linux Kernel Mailing List) last summer: https://lkml.org/lkml/2019/8/4/15
(Subject: »Let’s talk about the elephant in the room - the Linux kernel’s inability to gracefully handle low memory pressure«)
This type of out-of-memory problem continues to be a hard nut to crack.