There can be no consensus because there is no one answer.
On Windows without swap when you hit a remotely low on RAM point, things start going really poorly for some reason - random latency. So with 16 GB of RAM even I can't disable swap on Windows without some really strange performance characteristics, I run SSDs so I really wanted it off and I just stuffed more RAM in my box - with 32 GB it isn't a problem.
On Linux however, you can pretty much turn it off and everything will run smooth until you're actually out and then you lag badly briefly, Linux's oom-killer does its thing and all is good again within the span of a few seconds.
If you ASK about swapping on windows, you get people telling you that "Microsoft engineers are smart, don't disable swap and go <insert expletive here>" even if you asked something that is NOT about disabling swap.
So, I had this gamer laptop, i7, nVidia GPU, 8GB of RAM (when most machines had 2 or 4), but some stupidly slow 5k RPM HDD made for power saving and locked "noiseless mode", thus very slow seek too (ie: it moves the heads slowly to avoid making noise and for aerodynamic reasons).
I noticed that ever after I just booted up, RAM usage would jump to 6gb and the HDD would trash endlessy and make the machine unusable... after some research I found some interesting posts by MS employees about it:
Windows can "preemptively" use swap, it will write on swap things it thinks you might need to swap out. Sounds good on paper.
Also, Windows has several caching systems, that will write to "RAM" random crap.
One day that was particularly bad, I noticed that when I booted, Windows would immediately attempt to copy to RAM a gigantic binary file that was the sound files of a game I played a lot recently, this caused trashing due to reading the file, then, it would attempt to load other programs it had to, then page out immediately, and enter some crazy loop of trashing the I/O forever... Every time I opened the task manager and looked at the graphs, disk I/O would be constantly maxed out at 100%...
Disabling the VM made the laptop behave better (despite all the bugs Windows have when you disable VM).
But what I really wanted, was to change how the VM works... I wanted to keep the VM, and the caching, but change settings, for example I would set it to NOT page out anything at all unless RAM was used more than 80%, and also to never "cache" stuff unless HDD was actually idle and a good amount of RAM free. But sadly, this can't be done it seems, I got no useful answer on stackexchange sites when I asked this (But got a couple personal messages and e-mails full of expletives in many places where I asked about it, for some reason people get personally offended when the subject is virtual memory).
Oh, that's just superfetch, it's a service you can disable to reduce a bit the idle trashing after desktop has loaded.
Because of this memory pressure will be higher on a windows box. Pageing helps paper over this as the commit can be billed to the page file not RAM. Windows is smart enough to not write anything to swap until you actually use the page so in practice this is rarely a problem.
The benefit to this approach is you actually have a hope of recovering from OOM.
That's not true, you have to turn vm.overcommit_memory on in Linux for that to happen I believe. Which is off by default in most distros.
The default is to allow "sensible" overcommit whatever that means. From my experience whatever "sensible" is, really is sensible and I haven't had issue with that. You can also set it to allow all memory allocations, even "silly" ones (i.e. allocate 100GB memory on a system with 10GB RAM); or to refuse overcommiting memory.
Usually selecting sshd to kill, in my experience, rendering the server inaccessable.
* On a laptop to hibernate, which results in zero power consumption vs suspend which will drain the battery in a day or so
* I use tmpfs for /tmp and using swap as the backing is far more performant than regular filesystems
This seems absurd. You're running an in-memory filesystem backed by memory-on-disk? You weren't comparing to a journalled filesystem or something like that?
I consider files in /tmp to be temporary, and do not expect them to survive a reboot. (Actually I prefer they don't - less administration and housekeeping.) They also have random lifetimes ranging from fractions of a second to several days. And random sizes from zero length to gigabytes (eg making an ISO image).
With tmpfs RAM is used which provides the best performance since the filesystem is trivial. Memory pressure will cause swap to be used as needed. Files not accessed will end up in the swap and taking no RAM.
By far the fastest I/O is the I/O you don't have to perform.
If you're using a swap partition just for the sake of /tmp then it's the same difference, no?
No. The big difference is that regular filesystems try to do I/O to their backing device - heck that is their point, and what they do the vast majority of the time. tmpfs does not do any I/O. However I/O will happen when there is memory pressure by the swapper, but that is going to be rarer.
ie with tmpfs, swap is a spillover mechanism. With a regular filesystem, the underlying device is the primary mechanism.
Swap can also be used for actual swap on the occasions it is helpful.
Yes and no - aren't they just two ways of looking at the same decision? Regular filesystems will buffer, and when the system is low on memory it will flush buffers, using similar criteria to deciding whether to swap.
> Swap can also be used for actual swap on the occasions it is helpful.
Swap enables actual swap, sure. My experience is that it usually hurts more than it helps though.
That is the bit you are missing. Unwritten filesystem data is regularly flushed. The flush interval is often around 5 seconds. Lookup "pdflush" to get the gist, although things have changed since then. Same with laptop mode.
Quite simply if a file is created and lives for at least N seconds then there will be disk activity irrespective of memory pressure. N is 5, perhaps up to 30 seconds in normal use.
Even if the file contents aren't fully flushed, metadata is.
Swap is not strictly needed for this:
(it boils down to vm.swappiness=1)
https://wiki.debian.org/Hibernation/Hibernate_Without_Swap_P...
Still, it's possible to hibernate without having the drawbacks people have been complaining about in this thread.
for sure it is. Even for swap files inside an encrypted volume.
https://vadim-kirilchuk-linux.blogspot.com/2013/05/swap-file...
The crux is knowing the swap-file offset and passing that argument as resume_offset on boot.
Have a look. It's totally doable and you won't need to have an actual partition.
Not sure what you're referring to here. This story doesn't recommend eliminating swap...
So, it doesn't exclusively recommend it, but it concedes that there are use cases where it makes sense.
I sort of wonder if we'll see a 100% RAM, large memory laptop soon that boots from an SD-card or in a cryptographically secure fashion over 4G wireless networks, aggressively disables RAM for power saving and suspends well.