[cosarara97]

In my experience, a misbehaving linux system that's out of RAM and has swap to spare will be unusably slow. The process of switching to a tty, logging in, and killing whatever the offending process is can easily take a good 15 minutes. Xorg will just freeze. Oh, and hopefully you know what process it is, else good luck running `top`.

Until this is fixed, I'll just keep running my systems with very small amounts of swap (say, 512MB in a system with 16GB of RAM). I'd rather the OOM killer kick in than have to REISUB or hold down the power button.

Some benchmarks with regards to the performance claims would be nice.

[cdown]

> In my experience, a misbehaving linux system that's out of RAM and has swap to spare will be unusably slow.

Yeah, this is basically the main drawback of swap. I tried to address this somewhat in the article and the conclusion:

> Swap can make a system slower to OOM kill, since it provides another, slower source of memory to thrash on in out of memory situations – the OOM killer is only used by the kernel as a last resort, after things have already become monumentally screwed. The solutions here depend on your system:

> - You can opportunistically change the system workload depending on cgroup-local or global memory pressure. This prevents getting into these situations in the first place, but solid memory pressure metrics are lacking throughout the history of Unix. Hopefully this should be better soon with the addition of refault detection.

> - You can bias reclaiming (and thus swapping) away from certain processes per-cgroup using memory.low, allowing you to protect critical daemons without disabling swap entirely.

Have a go setting a reasonable memory.low on applications that require low latency/high responsiveness and seeing what the results are -- in this case, that's probably Xorg, your WM, and dbus.

[AstralStorm]

And a multigigabyte brick of a web browser.

[vanni]

You can use Alt+SysRq+f to manually call oom_kill.

[kam]

On many distros, this is disabled by default because there's a chance that the OOM killer will hit something important, like the screen lock. For Ubuntu, enable it in /etc/sysctl.d/10-magic-sysrq.conf.

[kuschku]

If you’re using logind, this isn’t a problem – if the screenlocker dies, it will be restarted up to 3 times (without revealing screen content), and if it is killed yet once more, your screen just won’t unlock (you can then unlock via a tty by logging into that and using loginctl session-unlock).

If the daemon responsible for this is killed, all your sessions will simply be killed.

In no situation will your screen unlock due to a process being killed (in contrast to the pre-logind world, where, if the screenlocker dies, your screen is free for all, as there the locker is just a fullscreen window)

[crististm]

In 2005 I was able to run Linux on 512MB RAM _without_ swap (on purpose - every day) without issues. Today it will bark at me on 8GB of RAM for not having swap enabled.

[mikekchar]

I'm running on an 8GB Linux box without swap and never even come close to running out of memory. If I don't have any VMs running, then it's pretty unusual for me to use much more than 1-2 gigs. It's interesting... one of my colleagues has serious problems with performance because he keeps running out of memory -- and I don't think he's doing anything unusual.

I think there is something wrong with some of the major distros. I got really fed up with Ubuntu because of random junk running without my approval and eventually migrated to Arch simply because I have a lot more control over configuration. I don't mean to trash one distro over another because each one has its strengths and weaknesses, but I'm been surprised at how bloated the average Linux install is these days. I'd love it if there was more attention paid to it.

[jcelerier]

> I'm running on an 8GB Linux box without swap and never even come close to running out of memory. If I don't have any VMs running, then it's pretty unusual for me to use much more than 1-2 gigs. It's interesting... one of my colleagues has serious problems with performance because he keeps running out of memory -- and I don't think he's doing anything unusual.

64gb here and 40gb used. Firefox alone uses 2 gigs with a mere ~30 tabs.

[gizzlon]

I run KDE, Firefox, Slack (browser based app), Chromium, VS Code (browser based app) (plus Gvim, shell etc) on Arch and it's currently steady at 3.9 GB (of 16)

Edit: Also be sure it's actually used: https://www.linuxatemyram.com/

[Doxin]

Browsers have a tendency to use some percentage of available RAM. Firefox using 40gigs on a 64gig machine doesn't mean it'll try to use 40gigs on a 8gig machine.

[kzrdude]

What function does the 0.5GB swap have?

[petecox]

I just wish Linux distro installers would make opting out the default option; no, I don't want to swap on my SSD. The last time I installed a distro, I still had to select the manual option for partitioning.

With an 8 Gig stick in my NUC, for normal desktop usage it never goes above 3.

[Karunamon]

And even then; they provision an absurd amount of it. I just did a fresh Ubuntu install. On a machine with 32 gigs ram, it creates a 32 gig swap partition by default!

[KozmoNau7]

They probably reason that you want your system to be able to hibernate, plus storage is cheap.

I have 8GB of swap for the 8GB in my laptop, for that reason.

On my desktop with 16GB, the w 2GB of swap it has is sometimes too little, and everything grinds to a halt.

[vinw]

32GB of SSD isn't that cheap!

[userbinator]

A last-ditch safety buffer, to induce the slowdown so that you'll recognise that RAM is running low and hopefully prevent from actually completely running out.

[black_puppydog]

By that time, my system is usually responding to simple keypresses with latencies >1min... :|

[phire]

I actually did this on a old laptop, setup 200mb of swap for 4gb of ram.

And it caused huge problems for me, would run out of swap while having plenty of free memory and then go cripplingly slow.

[inamberclad]

Set the swappiness lower.

[AstralStorm]

That only delays the inevitable. Try setting overcommit to 2 and ratio to 100, then note apps crashing.

[tmyklebu]

It doesn't go lower than 0. Swapping can still hose your machine when swappiness is set to 0.

[_ph_]

The point being is, that a system doesn't have to misbehave to allocate more memory than the total RAM. And in those cases, there is a very good reason to have swap space, and swapping won't impact the performance of the system - rather the opposite.

[AstralStorm]

Sure it does misbehave. The memory allocation failures should be handled properly and by that I mean not by crashing. Very few applications should require memory use beyond current free RAM. Especially not JVM, JavaScript VM, a web browser or even video player. Yet this silly heuristics in Linux lets it happen.

[_ph_]

No, that is not correct. If you have any idle processes, their memory can safely swapped out without impacting performance. The user should not be forced to quit programs as soon as they become idle. Also, as described in the article, a program often allocates pages, which also become unused and can be swapped out. In an ideal world, a program would not allocate pages which become idle, but that happens with complex software (and often depends on the user interaction, and thus is not completely predictable). Swapping out idle pages is a very simple solution to make more memory available for the active processes.