Does it actually work?

Posted Apr 10, 2025 13:51 UTC (Thu) by khim (subscriber, #9252)
In reply to: Does it actually work? by intelfx
Parent article: Three ways to rework the swap subsystem

> Because you are (either accidentally or deliberately) conflating swap performance and memory management strategy.

I guess. For me “swap performance” is a simple ratio: without swap XXX takes N seconds, with a swap XXX takes K * N seconds. And K is swap performance. There the question about how to more precisely measure XXX, obviously, but K looked like a non-ambiguous measure…

Sure, when you want to improve that ratio you would need some kind of more nuanced measures and maybe even introduce many other, lower-level, more tractable and less integral, numbers… but if we talk about “swap performance”… what else can you ever mean?

Virtual memory is “poor man's imitation of real memory” and swap is supposed to make it behave like real one… what other kind of measure may we want to talk about in the absence of any clarifications?

I even every explicitly wrote that I want to know what other natural way to measure “swap performance” is – preferably with explanation about who may want to know these numbers and why.

to post comments

Does it actually work?

Posted Apr 10, 2025 13:54 UTC (Thu) by pizza (subscriber, #46) [Link] (11 responses)

> I guess. For me “swap performance” is a simple ratio: without swap XXX takes N seconds, with a swap XXX takes K * N seconds.

You're missing the point where "without swap" something in the system (possibly even what you're using) will be force-killed due to insufficient memory.

If you have enough memory for your workload, nothing will ever get paged out.

Does it actually work?

Posted Apr 10, 2025 14:11 UTC (Thu) by khim (subscriber, #9252) [Link]

> If you have enough memory for your workload, nothing will ever get paged out.

Bingo! That means that swap is, essentially, a cheap replacement for an expensive extra RAM. And it has a theoretical, never achievable goal: be as fast as said extra RAM (it's not really possible to make it faster, I suspect).

> You're missing the point where "without swap" something in the system (possibly even what you're using) will be force-killed due to insufficient memory.

Not if you would buy extra RAM. Swap is, ultimately, a replacement for an extra RAM thus it's natural to compare it's speed to speed of a computer system with said extra RAM, isn't it?

After that you can look on list of workloads that you use, attach some $$ measure to the time that you are losing and then decide whether purchase of an extra RAM is worth it.

What other “swap speed” may you want to talk about and why? What would you do with these numbers and why?

Does it actually work?

Posted Apr 11, 2025 7:46 UTC (Fri) by taladar (subscriber, #68407) [Link] (9 responses)

I think you are missing the point that something being killed is fundamentally a lot better than the system becoming so slow that it will never finish its task before someone force reboots it to get a usable system back.

Does it actually work?

Posted Apr 11, 2025 8:05 UTC (Fri) by khim (subscriber, #9252) [Link] (8 responses)

In a cloud, for server applications it's often better: fault tolerance requirements means that you have some system to cope with death of any process (if only because you have to be ready to cope with sudden death of the hardware) – and restarting work on another computer is faster than using swap.

On a desktop becoming sluggish and 10x slow is much better then killing any processes, you only want to kill them when these are truly rogue processes that wouldn't ever produce any useful results.

Satisfying both requirements is hard but that doesn't give us any useful insights into what kind of “swap speed” one may need or want if the end result is that slowdown from the use of swap is so big that the only advice about tuning of swap that one may ever get is “ensure that swap is never used”.

Does it actually work?

Posted Apr 11, 2025 14:20 UTC (Fri) by kleptog (subscriber, #1183) [Link] (7 responses)

> On a desktop becoming sluggish and 10x slow is much better then killing any processes, you only want to kill them when these are truly rogue processes that wouldn't ever produce any useful results.

Only 10x would be ok. In practice it's something that's normally almost instant taking upwards of 20 minutes and your mouse pointer doesn't even move anymore. At that point killing something like firefox (which will restore from state anyway) is the right solution. Firefox is actually a good choice, because it has many subprocesses you can probably kill without the user even noticing.

I'd settle for: if moving the mouse pointer has no visual effect within 10 seconds, trigger OOM killer. I just have no idea how to go about implementing that. Actually, I'd like it to happen as soon as mouse movement becomes choppy, because at that point all is lost already. At that point I'm only desperately trying to get the mouse to the close icon in the top-right hoping clicking it gets through before the system hangs entirely.

Does it actually work?

Posted Apr 14, 2025 8:34 UTC (Mon) by taladar (subscriber, #68407) [Link] (6 responses)

Another good indicator might be if loading files during login takes more than a second or two. I am not talking about a whole desktop worth of applications starting up but just a terminal login. At that point I almost certainly want the slow application killed as my only purpose after completing the login.

Does it actually work?

Posted Apr 14, 2025 10:39 UTC (Mon) by khim (subscriber, #9252) [Link] (5 responses)

Login? What login? It wasn't uncommon for me to not be able to login on a text console because after I type my username and hit enter I never get to the Password prompt because getty kill that session for “inactivity” before that may happen.

I have no idea how much work /bin/login does, but couldn't imagine why that would take 5 minutes or more on any system where swap works properly.

This stopped, of course, after I gave up and switched to the use of Linux in container. With browser outside of it.

Does it actually work?

Posted Apr 14, 2025 22:14 UTC (Mon) by mbunkus (subscriber, #87248) [Link] (3 responses)

I can confirm khim's description. It's spot on & not hyperbole in the least. I've found myself in the exact same situation several times over the last several years. When this happens, no login method works at all (local console, ssh, display manager if it happens to be running on that server) due to how incredibly long each. and. every. key. stroke. takes. Debugging in such a situation is completely impossible, let alone fixing anything. Even if I manage to log in getting a process list takes multiple tens of minutes. The only sane thing to do is to hard reboot & eat the file system damage & loss of data.

And that sucks so much.

BTW, all of those cases were severs, not desktop systems.

Does it actually work?

Posted Apr 18, 2025 23:32 UTC (Fri) by Jandar (subscriber, #85683) [Link] (2 responses)

> The only sane thing to do is to hard reboot & eat the file system damage & loss of data.

I use ALT+SysReq+{s,u,s,b} in that order with a few seconds between. That's my way out of the semi-regular freezes apparently caused by swapping. Every time I have to do this I cross my fingers and pray to the filesystem-gods to spare my home directory ;-)

Does it actually work?

Posted Apr 24, 2025 16:00 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

SysRq is disabled by default now on some common distros. The point where you remember this is the point where you need it, but can no longer login to change this, of course.

Does it actually work?

Posted Apr 24, 2025 16:45 UTC (Thu) by farnz (subscriber, #17727) [Link]

Note, too, that SysRq's functions can be individually configured. On Fedora, the default setting is to allow sync, but nothing else; this is safe, since it's a function that the kernel will eventually do in the background, but not very powerful.

Does it actually work?

Posted Apr 24, 2025 16:08 UTC (Thu) by paulj (subscriber, #341) [Link]

Speaking of containers and browsers.... I used to run a system with a slow disk - plenty of RAM, but disk was slow enough that it was easy to trigger Linux's suicidal, "off a cliff edge", swap behaviour if I ignored the initial signs of slow-down from the bloated browser. I took to running the browser using 'systemd-run --user --slice -p MemoryMax=xG <browser>'. So it runs in a cgroup that will limit its memory use, and systemd-status --user can show you exactly how much RAM the entire group of browser processes is using, and it's also to kill the entire group - without needing to first run ps to find the process.