Re:In defense of swap: common misconceptions (2018)
by theamk on Wednesday April 20, 2022 @11:28PM
(#31105773)
I've never seen those livelocks before -- but I saw plenty of swap thrashing. How much memory did those VMs have?
Re:In defense of swap: common misconceptions (2018)
by linsomniac on Thursday April 21, 2022 @09:51AM
(#31109388)
I don't recall exactly, but probably 1-4GB. Not particularly low memory, but when something would come along that needed more memory than the system had, say a load burst, I was quite surprised to find the systems without swap just stop responding. I was expecting OOM killer to kill the offending process, the load balancer to remove it from the load, monitoring to say what process had gotten killed, but instead, even after waiting half an hour, the system was just wedged.
Re:In defense of swap: common misconceptions (2018)
by theamk on Thursday April 21, 2022 @10:05PM
(#31117432)
That seems pretty low, especially if this was 1GB of RAM. I'd use swap on such systems. I don't think there are any reasons today to buy physical machines with that little RAM, but I can see how you might have such VMs,
That said, I agree with other commenters that said this sounds like a kernel bug. I am wondering what was going on to wedge the system that bad. Would putting executables on tmpfs (so they cannot be paged out) helped?
Re:In defense of swap: common misconceptions (2018)
by bogomipz on Thursday April 21, 2022 @01:14AM
(#31106211)
Is "live lock" here page cache thrashing?
Re:In defense of swap: common misconceptions (2018)
by tsimionescu on Thursday April 21, 2022 @02:07AM
(#31106447)
I think it's usually code page thrashing, since executables and shared libraries can always be swapped back out to disk, only to be swapped back in when the process gets the next quanta of time to execute. If people say instruction cache misses are costly, wait till you need to read the next instruction from a 5400 RPM HDD...
Re:In defense of swap: common misconceptions (2018)
by bogomipz on Thursday April 21, 2022 @12:14PM
(#31111396)
Thanks, understood. However file-backed pages such as executables and shared libs are not written to swap space as the pages are just dropped and read back in from the regular(non-swap) filesystem no? Not that causes any less disk I/O of course but they are not anonymous pages which is generally what is written to swap. When I think swap I think of "written to swap" but maybe you mean swap in the general sense of paged out?
Re:In defense of swap: common misconceptions (2018)
by tsimionescu on Thursday April 21, 2022 @01:14PM
(#31112265)
Yes, I meant "swapped out" in the general sense of "paged out". On the other hand, if you have actual swap space, hot code pages will be much less likely to be paged out than colder anonymous pages.
My reading of this article is that he is specifically advocating NOT using it as a replacement for having adequate RAM.
My experiences, around 5 years ago, of running ~100 VMs without swap, basically confirmed the assertions in the article. Mostly the systems would run ok, but when they got into memory pressure they would live-lock. I had hoped for just OOM killing, which happened sometimes, but also sometimes the machine was just locked.
I switched over to having some small amount of swap, maybe 0.5-1GB on these boxes and haven't had a livelock since.
Plus, it's better to get unused pages out of RAM, which can be written to swap.
The one thing that HAS killed an SSD, in this case an Intel (320 series sticks in my head) is ZFS slog+L2ARC. Swap hasn't been a problem in my experience, but I also am not using swap to account for not having enough RAM.