Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stop making swap partitions—use swap files instead

gist.github.com

Post reply on HN
Print view View original

161–170 of 257 posts

Re: Stop making swap partitions—use swap files instead

#161

Post by al_borland »

Sohcahtoa82 wrote: post #157
SoftTalker wrote: post #135

Earlier quoted context omitted.

The old rule of thumb used to be 2x actual RAM for your swap file/partition size. That's probably not right with today's RAM sizes but I'm not sure what the current rule is. I just go with the Ubuntu installer default but I don't know if that's just a fixed number or computed in some way from amount of RAM available.

> The old rule of thumb used to be 2x actual RAM for your swap file/partition size. Which was always a dumbass rule that made no logical sense. Like, I remember a time when I had 4 GB of RAM and had my swap set to 8 GB. Then I upgraded to 16 GB of RAM. Theoretically, I shouldn't even need a swap file anymore, since my old setup would max at 12 GB and yet I never had OOM problems, but that "rule of thumb" would dictat…

This is why they went on to say it doesn’t make sense with modern RAM sizes.

I remember when I first came across this rule when getting into Linux for the first time. If memory serves, I had 256MB of RAM, so I set swap for 512MB, which seems perfectly cromulent.

Re: Stop making swap partitions—use swap files instead

#163

Post by anyfoo »

lokar wrote: post #158
anyfoo wrote: post #152

Earlier quoted context omitted.

This comes up every time swap is mentioned. Even if you have plenty of ram, having swap can help with performance. Why? Because the OS can page rarely used or seemingly downright unused dirty pages to swap, freeing up precious RAM for caches. I'd hazard a guess that especially if you run a ton of containers this can help, as there's probably a lot of memory getting dirtied on initialization of containers and their pr…

We looked at this a lot (it was a lot of money at our scale). A cgroup itself is just a few small data structures. And a reasonable process inside will only ever have a small amount of dirty memory it won’t ever use. Even then you can’t be sure of it packing neatly into whole pages. So, the typical saving is tiny, and the cost in unpredictable performance is quite bad. If you really do have an issue with “lost” dirty…

Fair enough, you looked and did the math. On my laptop (totally different use case), there is currently plenty of memory in the compressor.

Re: Stop making swap partitions—use swap files instead

#165

Post by PunchyHamster »

ducktective wrote: post #14

Tangential, but does anyone know why in 2026 and on Debian 13, my machine still hangs when some process exhausts RAM? Is there really no higher-priority kernel process to prevent total freeze of the system and send a SIGKILL to the culprit process when such a scenario happens?

It should eventually kill it. But having swap means it will try to use it as RAM which might delay/freeze system hard

Re: Stop making swap partitions—use swap files instead

#166

Post by lokar »

anyfoo wrote: post #163
lokar wrote: post #158

Earlier quoted context omitted.

We looked at this a lot (it was a lot of money at our scale). A cgroup itself is just a few small data structures. And a reasonable process inside will only ever have a small amount of dirty memory it won’t ever use. Even then you can’t be sure of it packing neatly into whole pages. So, the typical saving is tiny, and the cost in unpredictable performance is quite bad. If you really do have an issue with “lost” dirty…

Fair enough, you looked and did the math. On my laptop (totally different use case), there is currently plenty of memory in the compressor.

Yeah, personal (desktop/laptop) vs production are totally different. The production workload should be well understood and stable.

Re: Stop making swap partitions—use swap files instead

#167

Post by PunchyHamster »

fc417fc802 wrote: post #29
ducktective wrote: post #14

Tangential, but does anyone know why in 2026 and on Debian 13, my machine still hangs when some process exhausts RAM? Is there really no higher-priority kernel process to prevent total freeze of the system and send a SIGKILL to the culprit process when such a scenario happens?

> does anyone know why In a nutshell, overcommit. It's more or less broken by design but it's also incredibly practical so pretty much everyone does it. Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?

> Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?

In all cases, yes, in some cases no, you can make some heuristics for common use cases

For example, if I have 3 process hogs, on desktop I'd rather have my dev containers be killed, than anything I'm using.

Or on server, I'd rather have anything else but SSH/VPN software killed, because that's needed to debug the problem.

Re: Stop making swap partitions—use swap files instead

#168

Post by jenders »

Aurornis wrote: post #101
koala_man wrote: post #98

> Swap files have had the same performance characteristics as swap partitions for more than 20 years I thought so too, then I benchmarked it on a (spinning rust) HDD and found it was significantly slower: https://www.vidarholen.net/contents/blog/?p=1110 tl;dr: "In this test, using a swap file was surprisingly 50%+ slower than simply allocating a swap partition at the start of the drive, in spite of the low fragmentat…

> hen I benchmarked it on a (spinning rust) HDD Yes, but as your article notes HDDs have different performance characteristics depending on where the sectors are physically located on the platter. If you could force the swapfile to the same location on the platter it shouldn't perform differently. Most people are going to be using solid state where this doesn't matter.

+1. This test and its conclusions are flawed. See CAV/CLV

Re: Stop making swap partitions—use swap files instead

#169

Post by simoncion »

jeroenhd wrote: post #119
wongarsu wrote: post #40

Earlier quoted context omitted.

Notably windows doesn't use overcommit, and degrades much more gracefully under memory pressure. The biggest tradeoff is the amount of disk space consumed by a page file that also has to reserve space for unused pages that have been allocated but never been swapped in. On linux you can turn overcommit off, but there's too much software written around the assumption that overcommit is on

Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit. Systems with loads of RAM barely lose any storage to swap, but once they do get hit, they can get many gigabytes of swap space without user interaction. I believe macOS does it too, of course. I'm sure there are many reasons why Linux can't do that by default, but it's a real shame.

> Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit.

Given that one can have swap files, and can also use LVM LVs for swap, and given that userspace OOM killers that work way better than the built in one -for some workloads- exist, I see no reason why you couldn't have this on Linux. This comment [0] mentions a project that claims to do just that -and seems to use swapfiles to do it-, but I don't have any experience with it.

FWIW, I did find the README by the original author [1] far more informative than the one written by the new maintainer.

[0] https://news.ycombinator.com/item?id=49656129>

[1] https://pqxx.org/development/swapspace/>

Re: Stop making swap partitions—use swap files instead

#170

Post by genxy »

spijdar wrote: post #68

Why use swap files when we could have swap directories? ;-) Sprite had (IMO) a really interesting solution to swap. Each host had a directory, referenced by its host ID under the `/swap` directory, and inside that directory, individual segments of virtual memory would be saved: https://github.com/OSPreservProject/sprite/blob/master/src/k... Sprite overcommited memory like a modern OS, and stored segments individually…

Are you running Sprite in qemu or on hardware?

I ran a small Mosix cluster a couple times just for funsies. I had forgotten about Sprite as the other SSI cluster operating system. It is really too bad that this line of research trailed off.

Post reply on HN