One of the scenarios not mentioned is if you have a hilarious amount of RAM and little diskspace. I run with 1 GB of swap, VM swappiness set to 0 and 16gb of ram. I don't think I've ever gotten close to exhausting mem or even invoking oom. What real difference is made here? Is it just something I don't understand?
It really depends on the application and use case, but with lots of headroom there likely isn't a material difference (IE the application only uses 128MB of RAM, you're just not going to see it).
Where it would come into play in your use case, is say you have an application, that serves as an application, and can also serve files from disk, like a web app. Say the running application uses 8GB of RAM and the files on disk is 10GB. On your system with 16GB of RAM, the IO subsystem in the kernel will use leftover RAM as a cache on disk access. So even though your web server sends files from disk, in most cases it'll leave a copy in RAM, and then can just serve the file from RAM without waiting on the disks which are relatively slow. Our total dataset is 18GB though, so everything we're doing doesn't really fit in RAM with application + files usage.
This is where swap comes into play. Even though the application uses 8GB of RAM, maybe some of it doesn't get used very often. Where as the files on disk, the total 10GB get used almost constantly. What the kernel can do, is say, 2GB of the application, even though it's in use, we don't see the application ever using it. Maybe it's just some buffer or house keeping data, so it's not used frequently. We'll swap that out to disk, and our IO cache is now a little bit bigger, allowing it to speed up access to that 10GB of files always being used on the disk, speeding things up.
When the application does need that memory, the kernel will bring it back into main RAM, using some free memory that's maintained, or reclaiming some memory, which is slow. Instead of the RAM being instantly available, it has to wait for the kernel to do its work, which leads to engineers discovering in certain limited cases, if they disable swap, their applications get faster, since it doesn't block waiting for the kernel to do it's work in those cases.
If you don't have resource contention on the size of the application in RAM, and the amount of frequently accessed files / IO rate, you're not going to see any performance difference.
* The defaults swappiness setting on many distros can also be a little aggressive, which I suspect as lead to alot of these disable swaps. Although, as the article points out, this changed linux 4.0+, but I'm not familiar with the changes being referred to here.
I've run a lot of systems with gobs of ram and like 512M swap on FreeBSD. Linux is different than FreeBSD of course, but determining how much memory is being used / if you're running out is difficult. Watching swap stats is a better gauge.
If your swap i/o rate is high, you're probably thrashing, even if the usage is low; you're right on the edge, and need more ram (or fix bugs).
If your swap usage is growing rapidly, you've got an urgent problem; sometimes a little bit of swap lets you get in and fix something or at least shut it down nicer than OOM killer, sometimes it just gives you a more obvious record that you ran out of memory.
If your swap usage gradually climbs to say 50% over time, you might have a slow leak, or something to look at anyway.
Heh, I had to go from 16G to 64G because of how often I was hitting OOM when compiling big stuff (a few times per week at least). And that was in 2016...
