Linux: to swap or not to swap?

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