Linux: to swap or not to swap?

[SiliconWizard]

Probably a very common question, that has been answered numerous times. But one more time doesn't hurt, with possibly answers related to *recent* versions of Linux and various points of view.

So the question is, is a swap partition necessary for a desktop/workstation use, 64GB+ RAM and a Linux 6.x kernel?
What is the benefit in this particular case, and what would be any issue with not having any swap?

[RoGeorge]

I don't know the theoretical answer, but I never use hibernate, to not wear out the SSD (it saves the RAM to disk, which would be a huge write).  For a lesser wear out of the SSD, I used to take the effort and disable swap, and didn't had any problems running without swap.  At some point I've forgot to disable it, and now I've just checked and I have a 2GB swap partition (with zero usage of course - on a machine with 32GB RAM) .

I always use suspend to RAM as standby.

Swap can be a liability, too, there are some attacks to make the OS dump important info to swap, then try to read that after a reboot.  Don't know the details.

[DiTBho]

is a swap partition necessary for a desktop/workstation use, 64GB+ RAM and a Linux 6.x kernel?

it depends on how much ram you can consume in the worst case.
in my case, compiling cmake with 64Mb of ram (qemu/mips) requires 700Mb of ram in the worst case, so I need to add a swap file because I don t want to allocate more ram to the VM.

What is the benefit in this particular case, and what would be any issue with not having any swap?

benefit = not (issue = process killed because out of ram) 

[shapirus]

So the question is, is a swap partition necessary for a desktop/workstation use, 64GB+ RAM and a Linux 6.x kernel?

It is not neccessary until it is necessary.

[SiliconWizard]

Should have mentioned that the main drives would be SSD - although it's pretty common these days - so yes, one concern is excessive wear for maybe a not so good reason.

In theory, if you have a lot of RAM that you don't exhaust, swap use should be minimal, but not zero. Pages that are infrequently accessed will still be swaped out, even if there's ample RAM left. So in some use cases (in particular if you run your workstation for a long time without rebooting), the swap partition will still end up with significant stuff in it. I know this can be configured though to some extent.

I have no intention to use hibernate. But I do use standby quite often.

I have some experience with a no-swap install, as this is what I had done on my laptop (which has 16GB of RAM.) Never had any issue related to this, but I do not make a very intensive use the laptop, so there may be problems I've not run into.

Yes I know the main issue would be processes getting killed automatically, without any prior warning. Which admittedly could be annoying.

[shapirus]

Should have mentioned that the main drives would be SSD - although it's pretty common these days - so yes, one concern is excessive wear for maybe a not so good reason.

If you end up needing to use swap, the following will lower the chances of it being used until it's really necessary:

1. vm.swappiness=0 in /etc/sysctl.conf (or rather /etc/sysctl.d/something.conf)
2. use zswap.

p.s. Arch Linux wiki is awesome.

[ve7xen]

If I can, I always run desktops without swap. It hasn't been a real issue in years, I'd say since I was running 16GiB RAM.

I find that if my machine wants to hit swap, something is going very wrong and it's probably unresponsive and pissing me off already, and I'd really appreciate the OOMK stepping in and saving things.

[RoGeorge]

Pages that are infrequently accessed will still be swaped out, even if there's ample RAM left. So in some use cases (in particular if you run your workstation for a long time without rebooting), the swap partition will still end up with significant stuff in it

This what I've read in wiki and all kind of online searches.  However, in practice I've just looked and my desktop says 22.7GiB Used physical memory (32 GB RAM) and 0.0B Used swap memory. 

Using it as a daily desktop, electronics EDA, browsing (right now 411tabs in 29 windows in firefox and a few other browsers with only a handful of tabs), rare small programming/compiles, all opened since a week or so, with standby a few times a day, multimedia, youtube, etc. the home lab's computer, and ZFS (which is famous as memory hungry - in my usage it never made me left without RAM), and with all these, 0.0 Bytes swap.

If you are concerned about SSD wear out, the main writers for me are the Firefox browser - google how to move its caches to RAM.  Browsers are a pest, they have their own cache plus making use of temporary OS folders.

The second consumer of SSD writes for me is the systemd logging, which might write a lot if some applications are buggy or misconfigured (they always are a few that fill MB of logs daily).  Not systemd's fault, but it's impossible to disable systemdlogging.  My understanding so far is systemd won't boot if you mask logging, and will respawn the logging services if you kill or stop them.  At best redirect the logs to /dev/null.  Did that once when an application was so buggy that it filled the entire disk in one day.

[Karel]

Should have mentioned that the main drives would be SSD - although it's pretty common these days - so yes, one concern is excessive wear for maybe a not so good reason.

If you end up needing to use swap, the following will lower the chances of it being used until it's really necessary:

1. vm.swappiness=0 in /etc/sysctl.conf (or rather /etc/sysctl.d/something.conf)
2. use zswap.

p.s. Arch Linux wiki is awesome.

Code: [Select]

$ cat /proc/sys/vm/swappiness
60
$ sudo sysctl vm.swappiness=30
vm.swappiness = 30
$ cat /proc/sys/vm/swappiness
30

Occasionally, a system uses a high percentage of swap memory even when there is RAM available for use.
The culprit here is the 'swappiness' of the system. Yep, you read that right...swappiness. So now that
you know the lingo, you're ready to explore what it means. Swappiness refers to the kernel parameter
responsible for how much and how often that the system moves data from RAM to swap memory.

The default value for swappiness is 60; however, you can manually set it anywhere between 0-100.
Small values cause little swapping to occur, whereas high values can cause very aggressive swapping.
A value of zero causes no swapping at all to occur, so if you want to minimize swapping to its lowest
possible value without turning it off, you should set it to at least one.


https://www.redhat.com/sysadmin/clear-swap-linux

[SiliconWizard]

I'll probably set up a swap partition and adjust the swappiness parameter.  zswap is default on recent kernels as far as I've read.

If wear is a concern, one could always dedicate a small (and thus cheap) SSD to the swap partition. If it ever wears off, no harm done, just change it.

One can find decent 240GB SATA SSDs for as low as $20-$25. May not even be anything to fret about.
I could set up two partitions on it, one for the swap and one for any frequently accessed cache such as browser caches. Non-critical data, no wear for the main SSD(s).

[magic]

Is it useful, though?

There are two advantages I can think of.

1. Needing more memory allocated by processes than physical RAM. With 64GB, maybe this doesn't affect you.
2. Swapping out rarely used data to keep more files in page cache. Is it really much difference with fast SSDs?

I have a desktop machine with 32GB RAM and no swap. It works OK.

Yes I know the main issue would be processes getting killed automatically, without any prior warning. Which admittedly could be annoying.

The really annoying thing is the system being almost out of RAM, with about zero memory left for page cache, constantly re-fetching executable code from disk just to keep the processes running. 100% disk utilization, slow as molasses, but nothing gets killed yet. Particularly dreadful with spinning rust.

I find that if my machine wants to hit swap, something is going very wrong and it's probably unresponsive and pissing me off already, and I'd really appreciate the OOMK stepping in and saving things.

This is generally true, particularly if it hits swap for reason #1.

Although I find that long-running web browsers, particularly with loads of open tabs, particularly with loads of ads, are able to eat up pretty much any amount of memory. But the solution here is to deal with the root cause, I guess.

edit
Note that if you ever feel like having (more) swap, you can always create and enable a temporary swap file. You won't be able to hibernate/resume from it (easily), but what the heck. This is how Windows avoids having swap partitions.

[ve7xen]

The second consumer of SSD writes for me is the systemd logging, which might write a lot if some applications are buggy or misconfigured (they always are a few that fill MB of logs daily).  Not systemd's fault, but it's impossible to disable systemdlogging.  My understanding so far is systemd won't boot if you mask logging, and will respawn the logging services if you kill or stop them.  At best redirect the logs to /dev/null.  Did that once when an application was so buggy that it filled the entire disk in one day.

You can configure journald not to write to disk at all, and keep logs in RAM only with storage=volatile in journald.conf.

[SiliconWizard]

The second consumer of SSD writes for me is the systemd logging, which might write a lot if some applications are buggy or misconfigured (they always are a few that fill MB of logs daily).  Not systemd's fault, but it's impossible to disable systemdlogging.  My understanding so far is systemd won't boot if you mask logging, and will respawn the logging services if you kill or stop them.  At best redirect the logs to /dev/null.  Did that once when an application was so buggy that it filled the entire disk in one day.

You can configure journald not to write to disk at all, and keep logs in RAM only with storage=volatile in journald.conf.

Yeah, of course that kind of defeats the purpose of journaling to a large extent, but certainly a solution if you want to avoid wear from logging.

Can systemd log to a specific dedicated mount point?
If so, one could do as I suggested for the swap and cache files, use a dedicated drive for this. Considering this is frequently accessed, but not critical data, and that would leave your other storage alone.

[julian1]

Some reasons to avoid dedicated swap partitions are - extra install complexity, security if not encrypted, possible issues around wear-leveling with ssd, never desirable for a public server where any paging affects response time.

I found swap files are a pretty flexible alternative, and quick to setup up for occasional temporary need,

(from old notes),

Code: [Select]

dd if=/dev/zero of=/mnt/4000Mb.swap bs=1024 count=4000000
chmod 600 /mnt/4000Mb.swap
mkswap /mnt/4000Mb.swap
swapon /mnt/4000Mb.swap
cat /proc/swaps

 

[golden_labels]

Toto, we are not in 1990s anymore! Swap is not “spare, slower RAM” and almost never⁽¹⁾ should be used like this. If nowadays one asks about swap in the context of running out of memory, one is doing something wrong™.

Let’s put aside the obvious hibernation case. On a running system, swap is a mechanism of increasing system performance. Swap acts as a backing storage for anonymous pages. It gives the kernel some air to breathe. Instead of having unneeded anonymous pages wasting precious RAM space, the kernel may use that space for storing actually useful data.

The right picture to see is not: there is RAM for data and, if there is not enough of it, swap is used. While a bit imprecise, the much accurate picture is: everything is always stored on disk and RAM acts as a cache. Putting it in a bit different terms: you are always using a kind of “swap” (you have no choice) — you can at most decide, how much you dedicate to anonymous pages. This picture also answers the supposed “swap increases latency”, “swap destroys your SSD” and similar claims. If you see excessive swap-related I/O decreasing throughput, it is also not caused by the use of swap. It is because you have not enough RAM for the given job. Trying to hide the problem by 1990s-style use of swap will not help.

Whether you choose a swap on a persistent storage medium or zram, depends entirely on your particular scenario. There is no one-fits-all answer, because the two primary factors — memory demand and swap bandwidth — differ greatly between systems. Test, choose whichever fits you better.

⁽¹⁾ The rare exceptions are specific workloads which either are designed to work with swap or swap is coincidently not getting in their way.

[ve7xen]

Let’s put aside the obvious hibernation case. On a running system, swap is a mechanism of increasing system performance. Swap acts as a backing storage for anonymous pages. It gives the kernel some air to breathe. Instead of having unneeded anonymous pages wasting precious RAM space, the kernel may use that space for storing actually useful data.

If pages are not needed, they will be reclaimed and used by the kernel to do whatever it wants, whether or not they are backed by swap. Anonymous pages that have been written to and need to be kept alive are eligible to be swapped, but the kernel can't predict their future, and if they are swapped out, latency on the next access will go through the roof. So in general, the kernel avoids doing this unless it is in memory pressure. Presumably the application allocated that memory anonymously for a reason, instead of mmaping a file.

The right picture to see is not: there is RAM for data and, if there is not enough of it, swap is used. While a bit imprecise, the much accurate picture is: everything is always stored on disk and RAM acts as a cache.

This is less correct than the naive idea you are trying to refute, which is overly simplistic but basically correct. You even mentioned anonymous pages yourself. Backed pages are an important use of RAM for code and file I/O, but the vast majority of memory utilization on most systems is not file-backed, it's just whatever working memory your browser and whatnot needs, which will never be written to disk (unless it gets swapped there). So one of RAM's roles is to act as a buffer & cache between the OS and non-volatile storage, but that is not its only role by any stretch.

For example on the machine I am typing this right now, there is more than 3x anonymous memory active than file-backed memory:

Code: [Select]

Active(anon):    7137752 kB
Inactive(anon):    28468 kB
Active(file):    2246060 kB
Inactive(file):    40464 kB


If you see excessive swap-related I/O decreasing throughput, it is also not caused by the use of swap. It is because you have not enough RAM for the given job. Trying to hide the problem by 1990s-style use of swap will not help.

This is more or less true, as it was in the 1990s as well, and sometimes it is the only solution - but on the kind of machines we're talking about, desktop workloads with 32-64GiB of RAM, it's rarely needed. But whether or not you need the swap, the kernel will opportunistically use it to prepare pages to be evicted quickly. Having it enabled will definitely increase writes to your storage, whether the kernel ever actually commits pages there or not.

Is it possible that performance can be improved by swapping out very infrequently used anonymous pages in favour of more file cache or holding on to mmaped files longer in memory or some other opportunistic use? Sure, it sounds plausible, but as long as the kernel is choosing to leave gigabytes of memory completely free and unused (which is normal on my machines), including for 'free and zero-cost to evict' things like file cache, at least with the current virtual memory implementation it doesn't seem likely to me that you'd actually see any benefit outside of tuning some specific pathological workload that otherwise performs poorly. Especially as non-volatile storage performance has become an order of magnitude better with NVMe, which reduces the relative benefit of file cache too, meaning the kernel should be even less likely to want to use memory this way.

[golden_labels]

If pages are not needed, they will be reclaimed and used by the kernel to do whatever it wants, whether or not they are backed by swap.

Kernel is now deleting data randomly? A new thing to me! No, they will not be reclaimed. Anonymous pages continue to exist until all processes release them. Kernel can do nothing about this.

Anonymous pages that have been written to and need to be kept alive are eligible to be swapped, but the kernel can't predict their future, and if they are swapped out, latency on the next access will go through the roof. So in general, the kernel avoids doing this unless it is in memory pressure. Presumably the application allocated that memory anonymously for a reason, instead of mmaping a file.

Yes, kernel does not evict pages from RAM unless it needs RAM. Any pages, not only anonymous. This is obvious, almost a tautology. What was the goal of mentioning this?

This is less correct than the naive idea you are trying to refute, which is overly simplistic but basically correct.

Whatever you think of the picture I presented, the refuted idea is not “naïve” or “simplistic”. It is outdated and incorrect in terms of how memory management works today and for what kind of operation it is being optimized.

You even mentioned anonymous pages yourself. Backed pages are an important use of RAM for code and file I/O, but the vast majority of memory utilization on most systems is not file-backed, it's just whatever working memory your browser and whatnot needs, which will never be written to disk (unless it gets swapped there). So one of RAM's roles is to act as a buffer & cache between the OS and non-volatile storage, but that is not its only role by any stretch.

One can’t make an argument against a statement by negating the statement and using that negation as the argument. And this is what you did here, I believe. “Your picture is wrong, because: let’s assume the picture is wrong, therefore it is wrong”. Perhaps there is some miscommunication in either direction?

For example on the machine I am typing this right now, there is more than 3x anonymous memory active than file-backed memory:

Then in my opinion your system is having not enough RAM.⁽¹⁾ If we are in the “for example” territory: on my machines:

Code: [Select]

Active(anon):    1122960 kB
Inactive(anon):   536088 kB
Active(file):    3026396 kB
Inactive(file):   412788 kB

Code: [Select]

Active(anon):      20384 kB
Inactive(anon):     2604 kB
Active(file):      89520 kB
Inactive(file):   431008 kB

This is more or less true, as it was in the 1990s as well, and sometimes it is the only solution

But in 1990s it was both the accepted remedy to use swap and the goal of having swap in the first place. Nowadays it is neither the solution, nor a goal of having swap. The general movement recently is to even abandon swap altogether as inherently harmful. With a countermovement of people subscribing to the view explained by Chris Down, to which I myself belong.

but on the kind of machines we're talking about, desktop workloads with 32-64GiB of RAM, it's rarely needed. But whether or not you need the swap, the kernel will opportunistically use it to prepare pages to be evicted quickly. Having it enabled will definitely increase writes to your storage, whether the kernel ever actually commits pages there or not.

The same hypothetical argument can be made in the opposite direction: that the kernel may in some circumstances force dirty file-backed pages earlier than needed, increasing writes. In both cases for a 64GiB systems I do not see this being a significant issue.

⁽¹⁾ With an exception of a particular situation, when one works mostly with webapps. Which by their very nature are ephemeral and must be stored in anonymous pages.

[shapirus]

A value of zero causes no swapping at all to occur

This statement is false.

[magic]

Let’s put aside the obvious hibernation case. On a running system, swap is a mechanism of increasing system performance. Swap acts as a backing storage for anonymous pages. It gives the kernel some air to breathe. Instead of having unneeded anonymous pages wasting precious RAM space, the kernel may use that space for storing actually useful data.

If pages are not needed, they will be reclaimed and used by the kernel to do whatever it wants, whether or not they are backed by swap. Anonymous pages that have been written to and need to be kept alive are eligible to be swapped, but the kernel can't predict their future, and if they are swapped out, latency on the next access will go through the roof. So in general, the kernel avoids doing this unless it is in memory pressure. Presumably the application allocated that memory anonymously for a reason, instead of mmaping a file.

He obviously meant "unneeded" as "not needed right now".

Linux does swap out rarely accessed anonymous pages to make room for page cache growth. The balance between swapping out anonymous pages or evicting page cache slots is controlled by vm.swappiness and it applies when memory is needed for any purpose, including cache.

The same concern about latency of swapped out anonymous pages also applies to evicted file backed pages. You can't universally win by arbitrarily prioritizing one over the other.

The right picture to see is not: there is RAM for data and, if there is not enough of it, swap is used. While a bit imprecise, the much accurate picture is: everything is always stored on disk and RAM acts as a cache.

This is less correct than the naive idea you are trying to refute, which is overly simplistic but basically correct.

It is more correct for reasons given above. The former behavior only occurs with vm.swappiness=0.

In other words

majority of memory utilization on most systems is not file-backed, it's just whatever working memory your browser and whatnot needs

quite often, yes

which will never be written to disk

no

(unless it gets swapped there)

this is a tautology

Is it possible that performance can be improved by swapping out very infrequently used anonymous pages in favour of more file cache or holding on to mmaped files longer in memory or some other opportunistic use?

Exactly.

Sure, it sounds plausible, but as long as the kernel is choosing to leave gigabytes of memory completely free and unused (which is normal on my machines), including for 'free and zero-cost to evict' things like file cache

Not sure what you mean by that. And page cache is "zero cost" to evict only if you don't need the same file later.

at least with the current virtual memory implementation it doesn't seem likely to me that you'd actually see any benefit outside of tuning some specific pathological workload that otherwise performs poorly.

Such pathological workload has already been mentioned. A web browser with 100 tabs, each downloading infinite number of ads in the background and keeping them referenced somewhere so they aren't garbage collected by the browser. The stale junk is (hopefully) not accessed, so it can drift to swap and leave RAM free for more useful things.

Especially as non-volatile storage performance has become an order of magnitude better with NVMe, which reduces the relative benefit of file cache too, meaning the kernel should be even less likely to want to use memory this way.

The same NVMe makes it a nonissue to swap in an anonymous page, meaning the kernel should be even less likely to want to use memory for anonymous pages.


And this is the reason why having or not having swap is no longer making that much perceptible performance difference, and the less difference it makes the harder it is to tell whether it's better or not, and more stupid arguments will be had about it

[RoGeorge]

I do not understand the following:
- the desktop has 32GB of RAM
- the install wizard created a 2GB swap partition (seems negligible small when compared with the amount of RAM)

If I compare that 32+2 GB install, with another machine that has 34GB RAM (not 32) and NO swap, which one will run faster?  The 32GB RAM machine, or the 34GB RAM machine?  Same OS, same load.

[DiTBho]

Just thinking, you can buy a small HDD and use it only as swap device and temp files.

Partition1 swap
Partition2 temp

It will make long life and prosper for your SSD.

[magic]

If I compare that 32+2 GB install, with another machine that has 34GB RAM (not 32) and NO swap, which one will run faster?

I doubt you will find a scenario where 32GB + 2GB swap is better than 34GB.
The best you can do with swap is dump the lest important 2GB of "anonymous" allocations there.
The 34GB machine will simply keep these data in RAM (no other choice) and have the same amount left for other stuff.

One potential exception is if you have some "clever" applications which knows how much RAM you have and sizes its memory use to fill it all.
But then it's debatable if it's still "same load" on both machines.

And of course the only right answer is to expand from 34GB to 48GB or 64GB, as possible

[RoGeorge]

OK, thank you.  To rephrase the question, if I have no swap, my 32GB RAM desktop goes belly up if somehow it runs out of RAM, right?  Same will do if I have only 30 GB RAM + 2GB swap, right?  For my desktop usage 30 or 32 GB is the same, never run out of RAM so far.

It was never clear to me:  Are there any hidden advantages, or maybe hidden needs for the OS, to keep a swap as long as I only use half of RAM?  Do I have to have a swap if the physical RAM is plenty?

Is the swap needed because it extends the amount of RAM, or is it also needed because it will help the OS fail graciously (vs an allegedly sudden fail when the OS only has RAM)?

[ve7xen]

Kernel is now deleting data randomly? A new thing to me! No, they will not be reclaimed. Anonymous pages continue to exist until all processes release them. Kernel can do nothing about this.

What was meant by 'not needed' if not 'released'? If they are not released, they are needed.

Anonymous pages that have been written to and need to be kept alive are eligible to be swapped, but the kernel can't predict their future, and if they are swapped out, latency on the next access will go through the roof. So in general, the kernel avoids doing this unless it is in memory pressure. Presumably the application allocated that memory anonymously for a reason, instead of mmaping a file.

Yes, kernel does not evict pages from RAM unless it needs RAM. Any pages, not only anonymous. This is obvious, almost a tautology. What was the goal of mentioning this?

Memory is not necessarily backed by disk unless that is what the application asks for, and if that's not what the application asked for, it wanted working RAM, not disk. This should also be obvious.

This is less correct than the naive idea you are trying to refute, which is overly simplistic but basically correct.

Whatever you think of the picture I presented, the refuted idea is not “naïve” or “simplistic”. It is outdated and incorrect in terms of how memory management works today and for what kind of operation it is being optimized.

No, memory is not disk cache primarily. It is volatile working storage, and not generally connected to disk at all, and to suggest so is absurd. This should be self-evident by the fact that a system can operate just fine without swap, or without enough swap to cover all anonymous allocations, in which case the RAM fundamentally cannot be simply 'disk cache'. It can't even be viewed logically as such, there simply is no expectation of disk backing for anonymous memory. Even if swap is present, a page can nominally exist only in RAM or only on disk, or on both; this not the behaviour of a cache.

One can’t make an argument against a statement by negating the statement and using that negation as the argument. And this is what you did here, I believe. “Your picture is wrong, because: let’s assume the picture is wrong, therefore it is wrong”. Perhaps there is some miscommunication in either direction?

I assume that must be the case. I demonstrated why your picture is wrong - the existence of anonymous memory, which is not, by default, backed by disk. Ergo, memory is not disk cache.

This is more or less true, as it was in the 1990s as well, and sometimes it is the only solution

But in 1990s it was both the accepted remedy to use swap and the goal of having swap in the first place. Nowadays it is neither the solution, nor a goal of having swap. The general movement recently is to even abandon swap altogether as inherently harmful. With a countermovement of people subscribing to the view explained by Chris Down, to which I myself belong.

but on the kind of machines we're talking about, desktop workloads with 32-64GiB of RAM, it's rarely needed. But whether or not you need the swap, the kernel will opportunistically use it to prepare pages to be evicted quickly. Having it enabled will definitely increase writes to your storage, whether the kernel ever actually commits pages there or not.

The same hypothetical argument can be made in the opposite direction: that the kernel may in some circumstances force dirty file-backed pages earlier than needed, increasing writes. In both cases for a 64GiB systems I do not see this being a significant issue.

On this I mostly agree. From a technical point of view, swap should not be actively harmful, but I also don't view it as particularly necessary. If you have enough RAM, you shouldn't be worried about file cache being insufficient either, and with fast SSDs it is less of an issue. It's the same as ever - if performance isn't good enough, just buy more hardware! In my experience though, thrashing under memory pressure (with desktop workload) remains a major problem, and is made significantly worse by prolonging activation of the OOM killer, which is in effect what swap does. So for usability's sake I generally just disable it. Maybe it can be tuned to behave better under those pathological conditions, but it doesn't seem worth the effort.

Data on write load with and without swap would be interesting to see, but I agree it's practically irrelevant.

[ve7xen]

OK, thank you.  To rephrase the question, if I have no swap, my 32GB RAM desktop goes belly up if somehow it runs out of RAM, right?  Same will do if I have only 30 GB RAM + 2GB swap, right?  For my desktop usage 30 or 32 GB is the same, never run out of RAM so far.

Yes, if it actually runs out, which means all file cache has been evicted and there's nothing left for the kernel to reclaim. Then it will invoke the OOM killer, which will choose a process to kill, in order to make more memory available. If swap is available, then the same situation will lead to thrashing as active pages are swapped on and off disk as they are needed, which can make the system barely usable. Personally I prefer the killer on a desktop.

It was never clear to me:  Are there any hidden advantages, or maybe hidden needs for the OS, to keep a swap as long as I only use half of RAM?  Do I have to have a swap if the physical RAM is plenty?

Is the swap needed because it extends the amount of RAM, or is it also needed because it will help the OS fail graciously (vs an allegedly sudden fail when the OS only has RAM)?

Swap is not needed at all, as long as you have enough memory and don't care about hibernate. The argument here is that it gives the kernel a place to stash memory pages that it doesn't think are likely to be used any time soon ('hidden browser tabs with ads' as given by example). If that happens, it frees that memory for opportunistic usage, such as file cache, which can improve the performance of disk I/O, which is often very relevant for interactive performance. Whether that really makes a noticeable difference on your system is going to depend on your workload and actual memory utilization, as well as how much memory the kernel is able to page out this way, and how badly it kills performance when it has to bring it back. I'm of the opinion that opportunities to do this effectively are rare, and the benefit of an extra GB or two of file cache when you already have 20GB of it is minimal. The cost of doing so incorrectly (e.g. going back to one of those tabs and having to bring a ton of pages back) is pretty high by contrast, so I don't think it's worth it in practice. If you're on the edge though and have barely any file cache, the benefit might be worth it. If you do want to have swap on a system with plenty of RAM, I would recommend reducing vm.swappiness.