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.

[shapirus]

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?

The OOM killer will kick in and kill the process which it considers the trouble maker.

Same will do if I have only 30 GB RAM + 2GB swap, right?

Yes, except that the OOM killer will kick in a little bit later, because it will take slightly longer to run out of memory, because disk-backed swap is slower than RAM.

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?

No.

Do I have to have a swap if the physical RAM is plenty?

No.

In addition, there's a curious fact that some software even refuse to run if swap is enabled on the system (e.g., kubernetes).

Is the swap needed because it extends the amount of RAM

Yes. Historically it was invented to allow the processes to allocate and use more memory than the amount of physical RAM without spending crazy money on additional memory modules at the expense of performance (disk-based swap is much slower).

I can imagine a use case, probably not too realistic, where having swap would be beneficial, in which two conditions are true:

- there is a process (or multiple processes) which need to use a lot of memory, but the data in that memory is accessed very infrequently;
- there is very intensive disk read access taking place, especially when the disk is slow.

In this case, it may be desirable to enable swap to allow the kernel to move rarely accessed memory pages into swap to free up as much RAM as possible for buffers/cache.

or is it also needed because it will help the OS fail graciously (vs an allegedly sudden fail when the OS only has RAM)?

There is (usually) no OS failure in the OOM situation. The OOM killer gets rid of the processes that it considers to be resource abusers and whatever is left continues normal operation. It's the total amount of memory that counts, not the type of it, save for the disk vs RAM speed that I mentioned above.

[RoGeorge]

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.

That's the bird eye view I was looking for.  Thank you.  Since I was asking for a home desktop, I'll prefer a sudden fail rather than disk trashing, especially trashing with a silent SSD.

[SiliconWizard]

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.

What did I say just above?
I was mentioning a "small" SSD instead though, as they have become quite cheap, will still provide much better performance when accessed, and if it wears out, it's absolutely no big deal.

[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.

What did I say just above?
I was mentioning a "small" SSD instead though, as they have become quite cheap, will still provide much better performance when accessed, and if it wears out, it's absolutely no big deal.

You said, since it's cheap so if it wears out, it's absolutely no big deal, I say ... ummm

My opinion, but "small" SSDs can be as cheap as you like and still will die if used for continuous I/O, while HDDs are also getting cheap and work better for that purpose.

Inferior performance? Yes SSDs are faster, and HDDs are fast enough, then, it depends on your purpose, for me, the best I can do is hybrid storage

• SSD -> RO, to load programs libraries, making it writable only on specific occasions (e.g. system update)
• HDD -> RW, to process stuff that need temporary storage + swap partition

Or, at least have the foresight to use two SSDs: one for the operating system, one for temporary files

• SSD#0 -> RO, to load programs libraries, making it writable only on specific occasions (e.g. system update)
• SSD#1 -> RW, to process stuff that need temporary storage + swap partition (cheap and easy replaceable)

so when SSD#1 dies ... only the latter dies and you don't have to rush to restore the system.

What I meant 

[rdl]

Just like flash drives, memory cards, etc., there's a manufacturing cost overhead that can't be avoided, so the smallest and cheapest you can buy constantly increases in capacity. And there is little savings in going small.

[SiliconWizard]

@DiTBho: I get it, this is just debatable. If you want a super long-term operating of your system without any hardware change, I agree. The HDD will (usually) win. My point here was that, for this use case where performance may still matter, but the data itself is temporary and non-critical, using a cheap SSD and having to change it every couple years looks like a pretty workable solution while not sacrificing anything.

But obviously it's 100% up to each individual situation.

[golden_labels]

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.

Others have already responded to the question directly, but let me make an important note here. Do not be focused too much on swap being 2 GB. If you used some wizard, don’t seek any deeper logic behind the choice of 2 GB. Doubtful there is any: there isn’t many choices. An arbitrary value, a result of some ancient or unfounded trade lore, or — though I admit I personally never heard about anything doing this⁽¹⁾ — an outcome of a statistical research (“fits most users”). The problem, which a wizard can’t overcome, is is that the amount of swap needed is tightly bound to your particular workload and whether you use hibernation.

In the distant past there were two “common knowledge” approaches. One was “as much as RAM”, the other “2× RAM size”. One comes from Microsoft Windows; the source of the other is more obscure, but appears to be somewhat related to enterprise usage of Linux. Both are ancient, devised when 4GiB RAM was nerds’ wet dream, and the Windows one is specifically bound to “swap is an emergency RAM” approach.

In my opinion the sanest approaches are:

• A blind one:⁽²⁾ just set swap to “a few gigs”. That may be not suitable for hibernation, if you have 32 GiB RAM. But otherwise: basically “just works”, doesn’t waste too much disk space in case you were wrong, in case of a catastrophic memory leak this size is bearable.
• If not using hibernation: the typical value you get from “Used” column in free -h. The reasoning behind is, that it gives the system an opportunity to push everything out of RAM. Which should (and will) never happen, but this is a ballpark estimate.
• If using hibernation: choose the percentage of cases in which hibernation should not fail and set swap to the corresponding percentile of memory used (as above, from free -h). The reasoning behind this is: it will provide enough space for hibernation to work. There are a few more factors to consider, than memory used, but typically they are countered by data being compressed for hibernation.

The latter two options should not be taken with religious rigour. I see them more as bringing focus to the most important factors than being a direct advice.

But I truly believe that, with systems offering that much RAM, we are at the time in which even above suggestions are becoming obsolete. And we need time to develop new ones.

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)?

Neither. For the first part see my post above. For the second: if an OOM condition occurs due to a runaway memory leak, this is a catastrophe one way or the other. The presence of swap doesn’t make it graceful. Quite opposite: the system gets blocked completely for a long time. This can be addressed with suitable cgroup settings for services and/or daemons like earlyoom or systemd-oomd. But with these in use the entire question becomes moot.

⁽¹⁾ I suspect I came across a few choices/guides, where this was the case, but this is merely my suspicion. No evidence. So I assume I never met with that.
⁽²⁾ I know, that in the tech crowd there is a strong tendency to make decisions, which at least give a feeling of being taken thoughtfully. But that has its drawbacks too: internal bikesheding and magical thinking. Sometimes it’s better to not have any technical reason, than being trapped into wasting time on following advice which only pretends to offer solid logic.

[DiTBho]

In the distant past there were two “common knowledge” approaches. One was “as much as RAM”, the other “2× RAM size”. One comes from Microsoft Windows; the source of the other is more obscure, but appears to be somewhat related to enterprise usage of Linux. Both are ancient, devised when 4GiB RAM was nerds’ wet dream, and the Windows one is specifically bound to “swap is an emergency RAM” approach.

that rule
         with k = { 0.0, 0.1, 0.2, ... 1.0, 1.1, 1.2, ... 2.0, 2.1, .... n }
         swap.size = k x ram.size
was/is an empiric approach based on statistical analysis.

my PPC-7550 cannot address more than 2GB of ram, the kernel is 32bit and cannot allocate more than 512Mbyte of stack per process.

At the moment the PSU is dead and i'm still trying to figure out how to fix it, during its golden ages it usually spent its time at compiling stuff, from the development of custom programs, to compiling "stage{1,2,3,4}" for Catalyst, so { cpp, cc1, ld, make, perl, python, lua, ... } have always been the most used processes, and rarely a single process in that list needs more than 200Mbyte of ram, as well as rarely I run more than two big Catalyst-processes in parallel, as well as rarely I need to compile C++ stuff.

Mozilla and Netscape were nice to be built in the early 2000s, once configured, and gcc from v2.96 to 4.1.2 have always been kind in terms of the required ram.

However, when years ago Firefox was written entirely in C++ (now it's an hybrid mess, impossible to be cross-compiled) , I remember there was very high swap pressure with more than 800 Mbytes consumed by gcc.4.5, that means 2.8Gbyte requires on a machine that physically address 2GB.

I remember a couple of "out of ram" crashes because I hadn't allocated any swap, thinking that 2GByte of ram was enough for everything, even because  in 2005, 2Gbyte was a rarity to have on a computer since very expensive.

RAM: 2GB
Swap: 0 <------------ k= 0.0, you assume the ram is already enough

So then my choice was 2GB of disk space instead of 1GB for the swap, as "coverage" safe (k = 1.0), just in case.

RAM: 2GB
Swap: 2GB <------------ k= 1.0

Probably k = 2.0 had/has a similar "coverage" choice behind its shoulders 

[DiTBho]

p.s.
moving from gcc v8.5 to v12 reveals that the new compilers consume 2x times the RAM, and if you don't have enough, that's where if you opted for higher k coverage for your swap.size you made a wise choice.

[Karel]

For me, the reason to add a relatively small swap partition, is just to "get notified by slowlyness" when
the system is about to run out of memory.
I'm thinking about to write myself a little desktop widget that notifies me when used ram reaches
a threshold. In that case I will not use a swap partition anymore.

[DiTBho]

For me, the reason to add a relatively small swap partition, is just to "get notified by slowlyness" when
the system is about to run out of memory.
I'm thinking about to write myself a little desktop widget that notifies me when used ram reaches
a threshold. In that case I will not use a swap partition anymore.

love this idea, just ...
if I implemented that monitor on my router, I am afraid it would light up and blink more than a Christmas tree 

[golden_labels]

For me, the reason to add a relatively small swap partition, is just to "get notified by slowlyness" when
the system is about to run out of memory.
I'm thinking about to write myself a little desktop widget that notifies me when used ram reaches
a threshold. In that case I will not use a swap partition anymore.

In most workloads you will receive that “notification” without swap too. Processes will wait for file-backed pages.

For a more civilized approach see Pressure Stall Information indicators. The feature is relatively fresh, so also often left unnoticed.

[rdl]

I just installed MX on a new-to-me old computer. I don't think it created a swap partition. All I remember doing was adjusting a slider to choose how to allocate the space between system and home. I'm pretty sure it was using the entire drive. My other Debian 10 computer has a swap partition bigger than the amount of RAM. I don't remember who's idea that was.

[BradC]

I've been using SSDs in my laptops since 2005, servers since 2010 and desktops since 2011. I always make the swap partition at least the size of RAM, and in some cases twice the size (xfs_repair can use a *lot* of RAM) and log/cache everything to disk.

In all cases, on all machines under all circumstances the wear on the SSD is such that the machine itself will be long dead before it exceeds the endurance of the flash. I've never seen it be close to an issue. I have seen plenty of people implement pathological workarounds to a purported issue though.

[magic]

the wear on the SSD is such that the machine itself will be long dead before it exceeds the endurance of the flash

Actually, I have done swap on SSD once upon a time and there were indeed no serious problems with it.
Large SSDs have high write endurance, mine still shows "medium wearout indicator" at 100/100.

The machine had 16GB RAM and swap was lightly used. I kept swap mostly for hibernation.

[DiTBho]

Code: [Select]

____________________________
|                           |
| reverse initiator         |
|                           |                             brdige
|     HBA     iSCSI        FC-optic ---------- FC-optic <========> SAS
|__             ____________|
   |           |
   |           |
   |           |
   |   PCI64   |
___|___________|____________
|      |DMA                 |
|   ___|_______             |
|  |          | allocated   |
|  | 31GB ram | to iSCSI    |
|  |__________|             |
|                         uart
|     SBC     PA8900        |
|             1GB  ram   eth0 ------ ssh
|             ramrootfs     |
|   GNU/Linux               |
| reverse initiator         |
|___________________________|

This is what I use for my-cross-compiling Catalyst 

It's an hacked a computer HBA installed into a mobo with 32GB of ram.

It's how to turn a "server" into a "SAS device", so a remote host can see it as "storage device" for temporary storage, which is 90% of what a tool-chain does.

/dev/sda <------ SDD, ReadOnly, kernel and rootfs ( { /var, /tmp, /build /user } are not mounted here)
/dev/sdb <------ HDD, ReadWrite, { /var, /user } are mounted here
/dev/sdc <------ rSAS, ReadWrite, { /tmp, /build } are mounted here

The host believes /dev/sdc is an iSCSI device, whereas at the end of the cable there is a computer which lends its "ram-disk" pretending to be a true block-device.

advantages:
1) it faster than an HDD (200Mbyte/sec read/write, limited by .. well .. the PA PCIX)
2) doesn't use any flash
3) provides more IOP

disadvantages
1) consumes more electricity than an SSD  (250Watt)
2) it's volatile
3) it's *very* expensive if you have to buy parts, I got mine for 200 UKP (as-is, damaged), and I was lucky

[SiliconWizard]

I don't really see a benefit compared to using a "cheap" dedicated SSD even if it doesn't have infinite lifetime (as I suggested), given the cost and power draw, but to each their own!

[nctnico]

For deskop systems I disable swap. There is no use for it with tens of GB of memory. Even a super fast SSD will be considerably slower. On embedded targets with a smaller memory, I setup a swap to prevent the OOM killer to kick in when an application reserves a lot of memory. In most cases the memory isn't even used. Ofcourse swappiness is set to 0

[alm]

For deskop systems I disable swap. There is no use for it with tens of GB of memory. Even a super fast SSD will be considerably slower. On embedded targets with a smaller memory, I setup a swap to prevent the OOM killer to kick in when an application reserves a lot of memory. In most cases the memory isn't even used. Ofcourse swappiness is set to 0

You might want to (re)read the article by Chris Down referenced by golden_label earlier in the thread, because you are falling into the traps like thinking setting swappiness=0 on a solid state system is a good idea, or that adding swap to a system with a lot of memory would somehow harm performance because the SSD is slower than your memory.

[BradC]

For deskop systems I disable swap. There is no use for it with tens of GB of memory. Even a super fast SSD will be considerably slower.

There's always use for swap. Infrequently (or not at all) parts of applications will get pushed out to swap in order to free up more memory for buffers & cache. My desktop has 64G of ram and still has nearly a gig pushed out to swap at the moment.

You often don't *need* swap, although even with 64G xfs_repair will OOM on a 4TB filesystem I have here. I need to provision another 128G of swap to get that to completion.

[shapirus]

There's always use for swap.

No, except for rare scenarios with heavy disk i/o and processes with big unused/rarely used chunks of data in memory. And not until Used+Buf/cache >= Total.

Here's my desktop where having swap wouldn't improve anything and could make the system less responsive if the kernel decided to move something to swap:

Code: [Select]

$ uptime
 11:47:31 up 32 days, 20:21, 30 users,  load average: 0.79, 1.01, 0.99

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        27Gi       3.5Gi       395Mi        32Gi        34Gi

Now, the point in the article referenced earlier,

5. On SSDs, swapping out anonymous pages and reclaiming file pages are essentially equivalent in terms of performance and latency.

is only valid for the "dirty pages", aka data in the buffers that has yet to be flushed to the underlying storage device and that will be forced to flush if the pages need to be reclaimed. If it's for the read cache, then the cost of reclaiming those pages is nowhere near the swap operations, which is typical for a desktop system where the disk workload is mostly read-only.

[alm]

5. On SSDs, swapping out anonymous pages and reclaiming file pages are essentially equivalent in terms of performance and latency.

is only valid for the "dirty pages", aka data in the buffers that has yet to be flushed to the underlying storage device and that will be forced to flush if the pages need to be reclaimed. If it's for the read cache, then the cost of reclaiming those pages is nowhere near the swap operations, which is typical for a desktop system where the disk workload is mostly read-only.

Here you assume that the anonymous pages and read cache are equally likely to be needed; but if the kernel decided to swap out the anonymous page, its algorithm predicted that the read cache page is more likely to be needed. Why would you want to take away this choice from the kernel by preventing it from swapping out anonymous pages to save a tiny amount of SSD storage? My desktop has been doing some heavy I/O over night and is still doing it, and with 32 GB RAM is currently sitting with 490 MiB free, 5.6 GB used, 26GB buffer/cache and 2.6 GiB out 8GiB swap usage for a number of hours. Clearly it hasn't needed those 2.6 GiB all morning. So the result without swap would have been 2.6 GiB less buffers / cache for the gain of a few GB SSD storage. Would the 2.6 GiB less buffers have negatively performance? I can't tell, but I'm certainly not missing the 8 GiB of SSD storage.

[shapirus]

Here you assume that the anonymous pages and read cache are equally likely to be needed;

Correct. It depends on the use case actually.

but if the kernel decided to swap out the anonymous page, its algorithm predicted that the read cache page is more likely to be needed.

Yes. This in turn means that the usefulness of swap depends on how accurate the kernel prediction algorithm is for a given use case. In my practice I rarely (if at all) used swap as anything but "emergency memory", but yes, sometimes it can be useful. Heavy disk I/O is a good hint that enabling swap should be considered.

[SiliconWizard]

So, for typical desktop use (not talking about server use), assuming you're actually not running out of memory, whether this actually gets your better performance on average in any given, real-life situation (as is often claimed here and there) is almost undecidable. You can only cherry pick very specific situations for which it actually would, and then claim that whoever disables swap is an idiot.

So you end up choosing enabling/configuring or disabling swap altogether based on a non-entirely rational decision, and some in this thread have evoked that it was even almost a political fight on some level.

[alm]

So, for typical desktop use (not talking about server use), assuming you're actually not running out of memory, whether this actually gets your better performance on average in any given, real-life situation (as is often claimed here and there) is almost undecidable. You can only cherry pick very specific situations for which it actually would

On average it will either improve performance by giving the kernel more options in how to most efficiently manage memory or just not make a difference. Only if you cherry pick very specific situations where the kernel gets it wrong might it negatively affect performance. Whether that's enough to warrant the effort and SSD storage to set up swap is up to the individual.

then claim that whoever disables swap is an idiot

There's a difference between saying "you're wrong for disabling swap" and "you're wrong for disabling swap with the goal of improving performance".

[nctnico]

The problem I have with swap is that I have applications open for several days before using them. With swap enabled, it takes time to activate those applications. There is more than enough memory in my system to work with so swap simply isn't necessary.

[DiTBho]

So, for typical desktop use (not talking about server use), assuming you're actually not running out of memory, whether this actually gets your better performance on average in any given, real-life situation (as is often claimed here and there) is almost undecidable. You can only cherry pick very specific situations for which it actually would

On average it will either improve performance by giving the kernel more options in how to most efficiently manage memory or just not make a difference. Only if you cherry pick very specific situations where the kernel gets it wrong might it negatively affect performance. Whether that's enough to warrant the effort and SSD storage to set up swap is up to the individual.

then claim that whoever disables swap is an idiot

There's a difference between saying "you're wrong for disabling swap" and "you're wrong for disabling swap with the goal of improving performance".

in both points you have well summed up my views about that 

[shapirus]

The problem I have with swap is that I have applications open for several days before using them. With swap enabled, it takes time to activate those applications.

This is exactly what happens. Linux will happily swap out a web browser or other memory-hungry applications which are always running, but can stay idle for prolonged periods of time (e.g., nights). And then, once the user tries to use them, the system needs to load the pages from swap, which has a negative impact on the UI responsiveness.

[alm]

And what do you think would happen under the same memory pressure without swap?

[shapirus]

And what do you think would happen under the same memory pressure without swap?

Nothing. The pages would be readily available in RAM.

[alm]

Nothing. The pages would be readily available in RAM.

You seem to think that without swap the kernel won't get rid of data in memory. It will, just only some types of data (file backed pages). Which it will also have to reload whenever the application becomes active again. Data that you're more likely to need than the data the kernel would have swapped out if it had swap.

I remember twenty years ago when computers had maybe 64MB of memory that programs you hadn't used for a while had to be reloaded from hard drive, which took forever. This was not specific to swap, however, and a sign of low memory and slow storage. Now both of these have improved, I don't see this problem anymore with swap enabled.

[Ed.Kloonk]

In a previous decade on a lousy 32-bit netbook, I recall (after checking free memory >= used swap memory), I used a script to periodically turn off and back on the swap to force the system purge the swap file to recover system snappiness without the need to reboot. Unlike other OS's. 

Can you even still do this now? (I'm in the swap minimal or even no swap camp)

[Karel]

In a previous decade on a lousy 32-bit netbook, I recall (after checking free memory => used swap memory), I used a script to periodically turn off and back on the swap to force the system purge the swap file to recover system snappiness without the need to reboot. Unlike other OS's. 

Can you even still do this now? (I'm in the swap minimal or even no swap camp)

Yes:

Code: [Select]

sudo swapoff -a ; sudo swapon -a

[shapirus]

You seem to think that without swap the kernel won't get rid of data in memory. It will, just only some types of data (file backed pages).

Correct, but only if there is not enough free memory for newly written malloc()'ed pages. It will then free up some buffer/cache pages.

In this situation, however, it will not:

Code: [Select]

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        20Gi       9.1Gi       369Mi        33Gi        42Gi
Swap:             0B          0B          0B

There's plenty of free memory for whatever use. And if something of the 33G of buffers/cache needs to be freed, it's not a big deal, because most of it, in my case, are "clean" pages, aka read file cache.

Which it will also have to reload whenever the application becomes active again.

No. Why? The application data (code and whatever data structures it uses) is already in memory. If the app is terminated and restarted, then yes, it will need to read from disk, unless the respective files, which are typically very small binaries, are cached.

I remember twenty years ago when computers had maybe 64MB of memory that programs you hadn't used for a while had to be reloaded from hard drive, which took forever.

I'm not sure what it means. Data have to be read from hard drive only when the app and/or its resources are not already in memory, be it data pages or file cache.

[magic]

Which it will also have to reload whenever the application becomes active again.

No. Why? The application data (code and whatever data structures it uses) is already in memory.

Code and and read only data sections are memory mapped into the process and treated mostly* like all other file-backed data - subject to eviction under memory pressure and then faulted-in when the process attempts to resume execution.

* one exception is that you can't modify an executable file which is being executed by a process

[shapirus]

Code and and read only data sections are memory mapped into the process and treated mostly* like all other file-backed data - subject to eviction under memory pressure and then faulted-in when the process attempts to resume execution.

I doubt that. But even if it is so, code is tiny. Most of the memory is taken by structures for which memory is allocated with malloc() and then written into. These cannot be evicted other than along with killing the process by the OOM killer.

[alm]

Correct, but only if there is not enough free memory for newly written malloc()'ed pages. It will then free up some buffer/cache pages.

In this situation, however, it will not:

So we're back to "if there's no memory pressure, the kernel is unlikely to evict pages, so it does not make much of a difference either way except possibly making available more memory for caching" as discussed on page 1.

No. Why? The application data (code and whatever data structures it uses) is already in memory. If the app is terminated and restarted, then yes, it will need to read from disk, unless the respective files, which are typically very small binaries, are cached.

If the kernel feels memory pressure, it will try to evict pages. Without swap anonymous pages are not an option, so clean file-backed pages containing code or data the application needs are more likely to be evicted from memory and will need to be read back from disk when needed again. To the user this appears like swapping, but this behavior is actually more likely without any swap space available, since the kernel has fewer pages to choose from to evict.

[shapirus]

...which boils down to:

- if you have enough memory for both apps and cache, you don't need swap;
- if you don't have enough memory for them, add more memory; enable swap only if you can't afford more memory or all the slots are already used.

[Norbert]

The problem I have with swap is that I have applications open for several days before using them. With swap enabled, it takes time to activate those applications. There is more than enough memory in my system to work with so swap simply isn't necessary.

If it is of any help, I have a 24GiB system running and have set vm.swappiness to 10 (in /etc/sysctrl.conf).
The system starts swapping very, very late and only quite moderate.
Swap is only used if some extreme build jobs run once a week. With little performance impact, swap is on a flash drive.

[nctnico]

Code and and read only data sections are memory mapped into the process and treated mostly* like all other file-backed data - subject to eviction under memory pressure and then faulted-in when the process attempts to resume execution.

I doubt that. But even if it is so, code is tiny. Most of the memory is taken by structures for which memory is allocated with malloc() and then written into. These cannot be evicted other than along with killing the process by the OOM killer.

Indeed. The kernel can not decide to discard data from memory at will because it doesn't know whether it is used or not. File backed pages is another word for disk caching. Disk caching can be useful at times but at some point it has diminishing returns. How large is the biggest file you work on? And how much memory would you need to keep that data in memory for 10 applications? A couple of hundred MB is likely more than enough. Many years ago I tested whether compiling buildroot (embedded Linux system consisting of kernel and all user space applications) would compile faster using a hard drive or SSD. It turned out it didn't make any difference (same PC with about 20GB of memory).

[alm]

Indeed. The kernel can not decide to discard data from memory at will because it doesn't know whether it is used or not.

This is not what anyone is talking about when talking about evicting from memory. The way virtual memory works is that the kernel can decide where and how to store the data. Whenever the page is hit it will trigger the kernel to load the data if necessary. So for a read-only code page that exists on disk, it can decide to remove it from RAM and load it back from disk if necessary. Without swap, that will be one of the likely targets, together with discarding cache or writing out buffers (which is more expensive).

File backed pages is another word for disk caching.

No, it's a word for data that's mmap'ed from a file as opposed to be mapped with the MAP_ANONYMOUS flag. The latter are called anonymous pages.

[nctnico]

Sorry, but an application will need to mmap a file onto memory specifically for your case to work. This unlikely for most applications. From what I've seen most applications will load a file into memory, break it into structures and write it back on disk when it is done. An exception may be databases but that is more appropriate for servers that run a narrow range of applications.

For normal desktop use, having swap degrades GUI responsiveness when switching to a different application after a while. On Windows this is even worse; in some cases it takes several seconds for an application to pop-up with swap enabled. I have been around computers long enough to know where swap is usefull and where it is not. For a desktop computer swap is more likely to degrade performance than improve it. Memory is cheap nowadays. Without swap an application that needs more memory (including mapping a file) than is available will simply run out at which point it is time to add more memory or enable swap. But until then, having swap is more likely to degrade performance than improve it.

If you read this article carefully enough, you'll see that avoiding swap (by having more than enough memory) is the best option by far for a desktop machine:
https://lwn.net/Articles/690079/

[golden_labels]

What the eye doesn’t see, the heart doesn’t grieve over. Swap is bad, because GUI gives visual feedback; the lack of swap is great, because non-GUI processes may at best blink I/O LED. /s

If swap affects GUI, maybe the system runs too many processes for its RAM (more likely) or it needs changing configuration (less likely) by limiting memory⁽¹⁾ with cgroups for offending services?

⁽¹⁾ That limits the entire memory, including file cache.

[nctnico]

If swap affects GUI, maybe the system runs too many processes for its RAM (more likely) or it needs changing configuration (less likely) by limiting memory⁽¹⁾ with cgroups for offending services?

That is not the case. There is more than enough RAM but with the default settings, appearantly unused memory gets swapped onto disk without giving any performance benefit at all because there is no memory shortage to begin with. Ofcourse you can resort to setting swapiness to 0 but not configuring a swap space is simply less work. With enough memory having swap is like having a solution looking for a problem (which doesn't exist).

[SiliconWizard]

 

[tatel]

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?

I would say no, unless you expect to be short on ram. We do have some 50 TP-Link WR841-ish routers here. They are 8/32 devices. We build a customized image for them without swap support at all. Mainly because we needed the space on flash to have other things. These are as stripped-down systems as we could do.That was on 2014. So far not just one problem we could identify as coming from having no swap. IIRC they have like 8 MB free ram at start, maximum (there are like 4 years since they are maintained by my fellow tech-profane neighbors)  Now we have to get new ones because we can't put any currently security supported OpenWRT on them anymore (since some years ago). BTW, we are not sure we could get any so-reliable devices so possibly we will update flash and ram chips instead. We do have uptimes in the several months range usually. It comes very handy since we are speaking of not-paid, not-for-profit work in this case. So we want to have almost zero maintenance.

After that, I never, ever had any swap on any machine, unless I expect it to be short on ram for some reason like big builds, video edition, etc. I think is *way* better to have more ram if needed and at all possible.

About SSD: You could mount /var and /tmp on a classic HD. Modern linuxes do a lot of short writings to disk and that goes to these partitions. My current machine (AMD Ryzen 7 3800X 8-Core, 32 GB RAM) amazed me the first time I booted it, because there were no start messages, just got directly into graphical login. After putting /var and /tmp on HD, boot time is about 3 seconds.

Alternatively, you could use Devuan to get rid of systemd and hunt for rutinary writing to disks. I do that on machines destined to have linuxcnc. Like Athlon 64 dualcores with 2-4 GB RAM

YMMV though, so take this with the customary grain of salt

[SiliconWizard]

About SSD: You could mount /var and /tmp on a classic HD.

Whether on a HDD or a separate SSD as I suggested (for performance, even if that means a slightly shorter lifetime of this one which would essentially contain just temporary data.)

The problem with this approach is that the mount point may not be available when the system boots until pretty late in the boot process, so you'd miss logging from most of the boot.
Do you have any tips to handle that? Would that entail making your own custom initramfs? (Which I'd rather not do, what a pain to deal with this at every kernel update.)

[tatel]

My dmesg and /var/log/sylog don't show any symptoms. No need to modify one thing, I would say

[alm]

Sorry, but an application will need to mmap a file onto memory specifically for your case to work. This unlikely for most applications. From what I've seen most applications will load a file into memory, break it into structures and write it back on disk when it is done. An exception may be databases but that is more appropriate for servers that run a narrow range of applications.

Have a look into /proc/*/maps. You'll see many processes mapping binaries, shared libraries, devices, data files like fonts or browser cache. Mmap is used all over the place in *nix applications because it allows the kernel to efficiently manage the memory. Currently on my desktop system running standard desktop stuff like browsers that has been on all day there are 122824 regions of file-backed maps, which does not correspond to 122824 files because many processes will mmap multiple regions of the same file. Still, it clearly shows that even on the average desktop file-backed memory mapping is ubiquitous.

Ofcourse you can resort to setting swapiness to 0 but not configuring a swap space is simply less work.

What do you think setting swappiness does? It sets a balance between file-backed pages (see above) and anonymous pages (memory not backed by files of devices, for example memory allocated by malloc()). So if you set it to a low value, instead of writing anonymous pages to swap it will evict file-based pages that also need to be read back from disk when they are needed. Pages that are probably more likely to be needed than the pages it would have written to swap. The only thing it will save on is writes if you're very concerned about storage lifetime (say a flash memory device without wear leveling).

Whether on a HDD or a separate SSD as I suggested (for performance, even if that means a slightly shorter lifetime of this one which would essentially contain just temporary data.)

Is this supposedly shorter lifetime based on fact or superstition? In my experience the economic lifetime of SSDs is far shorter than the technical lifespan. So a 60 GB SSD might be at the end of its life now? Who cares, I'll likely have replaced it by a higher capacity/performance model years ago.

After that, I never, ever had any swap on any machine, unless I expect it to be short on ram for some reason like big builds, video edition, etc. I think is *way* better to have more ram if needed and at all possible.

This is a false dichotomy: more RAM is generally good, but using swap does not prevent you from installing more RAM. The cost of the storage space on modern SSDs is negligible. You still same to have the mistaken idea that swap is there as a buffer if you need more RAM, rather than to improve performance by evicting rarely used pages that otherwise could not be evicted.

[nctnico]

There is no shortage, so why even evict rarely used (hint: there is no such thing as unused memory that is claimed/in use by an application) if it isn't necessary? Keep in mind that without swap, the kernel doesn't need to keep track of which pages are used regulary and which not. I completely fail to see where there is any performance gain from having swap in a system that has enough memory. It is more like the opposite because with more memory, the kernel needs to do more bookkeeping when swap is enabled.

[alm]

There is no shortage, so why even evict rarely used (hint: there is not such thing as unused memory that is claimed/in use by an application) if it isn't necessary?

Because for most workloads more cache is better. Some pages might only be necessary when you shut down your computer, or for remote access which you use once per month.

Keep in mind that without swap, the kernel doesn't need to keep track of which pages are used regulary and which not.

I feel like I'm repeating myself, but no this is not how it works. The kernel will still evict pages and need to keep track of which to evict, the eviction will just be limited to file backed pages. So instead of swapping out that anonymous memory allocated by a backup program that runs during the night, it might evict a font or shared library that you haven't used recently.

[magic]

(hint: there is no such thing as unused memory that is claimed/in use by an application)

In a perfect world

Keep in mind that without swap, the kernel doesn't need to keep track of which pages are used regulary and which not.

Still does. From a router with no swap support at all:

Code: [Select]

# cat /proc/meminfo
MemTotal:         126324 kB
MemFree:           96604 kB
Buffers:            2172 kB
Cached:             8808 kB
SwapCached:            0 kB
Active:             9816 kB
Inactive:           4456 kB
Active(anon):       4372 kB
Inactive(anon):       92 kB
Active(file):       5444 kB
Inactive(file):     4364 kB
blah blah

[NiHaoMike]

For well over 10 years, every PC I set up didn't have swap. Never had any problem with it.

[olkipukki]

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

On 64GB machine I keep a swap 'just in case' of 1/2 size of RAM.
Usually, couple VMs runs at same time, although a swap used rarely.

... and what would be any issue with not having any swap?

Trying to hibernate 256GB RAM Linux didn't end up well 

[SiliconWizard]

For well over 10 years, every PC I set up didn't have swap. Never had any problem with it.

That's also my experience, with the disclaimer - that I stated - that I haven't been running Linux for real, heavy workstation use, hence the question more aimed at this use case.
My uses have mostly been on a laptop (which has 'light' use) and a headless box that I use for development purposes. In both cases, no swap, and never had any trouble with it.

But this time, it would be for 'heavy' workstation use, and typically putting the machine in standby when not in use (no hibernation as I said), so potentially relatively long up times.

My conclusion so far is what has been said a few posts ago - I'm going to activate a swap partition on a small dedicated SATA SSD, that will also be used for cache files and otherwise content that changes frequently, so that I limit the wear on the much more expensive, NVMe SSDs that I have.