In defence of swap: common misconceptions
chrisdown.name
chrisdown.name
…but very much not equivalent in terms of how much you are wearing out your SSD.
> Swap can make a system slower to OOM kill
This is almost always actually a bad thing. Turning on swap means your system goes from randomly killing processes to suddenly running 100x slower than it used to and then randomly killing processes.
"The oom-killer generally has a bad reputation among Linux users. This may be part of the reason Linux invokes it only when it has absolutely no other choice. It will swap out the desktop environment, drop the whole page cache and empty every buffer before it will ultimately kill a process. At least that's what I think that it will do. I have yet to be patient enough to wait for it, sitting in front of an unresponsive system."
This is my experience as well. Maybe this could be mitigated with cgroup v2 by setting some processes to never swap so the user doesn't lose interaction with the system.
NVMe SSDs are fantastic.
Swap is what turns the deficient OOM killer from a minor to a major problem.
If you can honestly answer "How much swap do I need, then?", and the answer is not infinite, then you can just add that amount of RAM instead of swap and be done with it, no need for swap, unless you want to prepare for emergency.
"Ideally you should have enough swap to make your system operate optimally at normal and peak (memory) load." Ideally you should have enough memory to make your system operate optimally at normal and peak memory load. In a perfect world, everything would fit in CPU's SRAM and you wouldn't even need DRAM..
If however you have something like kubernetes, your apps move across hosts, you have memory scaling with use (e.g connections) and you have no idea what the load on the app will be, it becomes basically impossible to right-size the memory so other strategies come into play. Monitoring becomes king at that point.
On a modern desktop system 'emergency' is every day, thanks to modern Javascript and the modern web.
Those things need infinite ram.
Sure, huge compiles are much slower when they hit swap, but at least it's possible to run them with swap, while it would be impossible for me to do so without.. at least until I can afford to get a new computer which can fit more memory.
Old thinkpads (2012ish) run for a hundred bucks and some change, and some of them support up to 32 GB of ram, IIRC. The battery is a generic and replaceable component, too. They can last a lifetime! Or at least until FF et al renders 32 GB insufficient.
While upgrading for money works for some, less bloated software would work for everyone + no need to spend money to get acceptable build times + even if you have a super computer, you compilation times gets a lot faster. So aiming for less bloated software feels like a more noble goal than trying to convince people to upgrade their hardware.
I totally agree with you that less bloated software should be our goal. Although, realistically, if you're compiling a modern web browser you don't have much of a choice in the matter (unfortunately). I don't think that reducing bloat by an order of magnitude (i.e. a difference that would impact compile times) is on the radar of Chromium or FF.
So I have recommended disabling swap on systems in the past, but inline with the article, these are on systems that are largely dependent on application memory, and don't benefit from the IO cache prioritizing any application pages. As the article is pointing out, this isn't a hard and fast rule, but a tuning that needs to be done depending on the application, and using cgroups to fine tune this may be a better approach depending on the use case.
To recap: swap makes anon memory pages reclaimable, by offloading it to disk. This does not explain anything. Its basically "swap allows anon maps to be swapped"; so what?
>> You need to opportunistically handle the situation yourself before ever thinking about the OOM killer.
Or, just rely on OOM killer, minimal swap(so the application dont agony in low memory conditions) and restart policies. There are no reason to do the kernel work handling memory over-commit.
https://github.com/torvalds/linux/blob/15a2bc4dbb9cfed1c661a...
sudo apt install earlyoom #!/bin/bash
echo 1000 > /proc/$$/oom_score_adj
path_to_real_chromeI think you want "exec path_to_real_chrome".
Linux kills a Chromium process, leaving bigger memory hogs roaming around.
It is a mechanism for making more page types reclaimable.
Thanks for summarising...
(It's also slower. The reason we use partitions is to avoid invoking a whole heap of filesystem code every time we want to access some memory.)
A growing/shrinking swap file doesn't really add anything, especially if you're thinking a 1:1 relationship with memory and swap. To me it seems like 16GB of HD space isn't that big a deal.
You can also play around with swap performance if you want temporarily.
https://linuxize.com/post/create-a-linux-swap-file/
Yes, it's going to be slower since you're using a file in a filesystem rather than using a dedicated partition, but it would give you a way to test it out. Some workloads will do better since the unused pages will get sent to disk.
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.
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.
(I don't think Debian will run with so little memory anymore.)
With flash file systems, swap is a Bad Idea(tm).
However, whenever I disable swap, all manner of Linux systems freak out because they are used to never having to actually deal with out of memory (having swap on Linux means your entire system becomes totally unresponsive long before anything actually flags out of memory). Linux doesn't help this by overcommitting memory that it doesn't actually have.
As long as the POSIX fork/exec pattern is implemented with a CoW address space, you can just write all over memory to cause new physical allocations. There's no malloc ENOMEM return to check in this case.
(You can do this on Windows too via RtlCloneUserProcess and friends.)
You could "solve" this problem by implementing fork/exec to use copying instead of CoW (like Cygwin and PDP-11 Unix), but I don't think anyone wants that, especially because you'd usually throw away the work with exec() anyway.
That'd put you in the unusual position of forbidding any sufficiently large process from ever creating children. The kernel has no way of knowing whether a fork() will be followed by exec().