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

101–110 of 256 posts

Re: Stop making swap partitions—use swap files instead

#101

Post by Aurornis »

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.

Re: Stop making swap partitions—use swap files instead

#102

Post by spudlyo »

williebeek wrote: post #46

Remember when distros used complicated partition setups, one for /root, one for /var one for /home, a swap partition etc. Was always a bad choice because one of them would be at 99% while others would linger below 10% For swap, the best advice is to disable swap on your desktop, unless <8GB RAM. Really, I've never needed it and you probably won't either.

> For swap, the best advice is to disable swap on your desktop, unless That maybe reasonable advice if you never intend to hibernate your desktop. I like to shut my desktop down when I'm not using it, and it's nice to be able to quickly boot it back to the same state it was in when I went to bed.

Re: Stop making swap partitions—use swap files instead

#103

Post by rwmj »

nicman23 wrote: post #82
joshAg wrote: post #80

Earlier quoted context omitted.

Don't worry, it's not just you: https://lkml.org/lkml/2019/8/4/15 It's because linux is a toy OS. Specifically, it overcommits memory in the hope/assumption that it won't all be used at once, but doesn't have a way to gracefully degrade when applications collectively want to use more memory(+swap) than it actually has. You can turn off overcommit, but applications are designed with the overcommitting feature in mind,…

or use the system's oom ?

All I want is the oomkiller to always kill firefox. Somehow that's very difficult to achieve.

Re: Stop making swap partitions—use swap files instead

#104

Post by malwrar »

SoftTalker wrote: post #93

For a while since RAM sizes have gotten so big I would set up linux servers without swap at all. I figured what is a 2GB swap file going to do if the system has already exhausted 128GB of real RAM? I never saw any issues doing this, but I learned that linux ideally wants some swap space, which it will use for some kind of housekeeping stuff.

Any tips on measuring the impact of not having swap? I never use it on my machines for similar reasons.

Re: Stop making swap partitions—use swap files instead

#105

Post by rwmj »

rovr138 wrote: post #22
ButlerianJihad wrote: post #20

Earlier quoted context omitted.

I believe that you mean: https://en.wikipedia.org/wiki/Thrashing_(computer_science) Chris Siebenmann discusses when the OOM killer triggers: https://utcc.utoronto.ca/~cks/space/blog/linux/OOMKillerWhen Chris disables systemd-oomd after it obliterates his X session with no explanation: https://utcc.utoronto.ca/~cks/space/blog/linux/SystemdOomdNo...

> First off, this is exactly how systemd-oomd is supposed to behave under memory pressure. The documentation is specific on this; systemd-oomd itself says: > > [...] If the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it. [...] > By having the user@.service template be enrolled in systemd-oomd, Fedora made the cgroup that systemd-oomd would selec…

I'm a Fedora developer and I can assure you that Fedora's behaviour when it runs out of memory is still terrible.

Re: Stop making swap partitions—use swap files instead

#106

Post by cesarb »

> fallocate / chmod / mkswap

Why not "mkswap --size ... --file ...", which does these three things and more? For instance, according to the mkswap man page, "[...] sets the nocow attribute for newly created files [...]" which is a detail that seems to be missing from this gist.

Re: Stop making swap partitions—use swap files instead

#107

Post by ktm5j »

malwrar wrote: post #104
SoftTalker wrote: post #93

For a while since RAM sizes have gotten so big I would set up linux servers without swap at all. I figured what is a 2GB swap file going to do if the system has already exhausted 128GB of real RAM? I never saw any issues doing this, but I learned that linux ideally wants some swap space, which it will use for some kind of housekeeping stuff.

Any tips on measuring the impact of not having swap? I never use it on my machines for similar reasons.

Worst thing that's ever happened to me is having processes randomly killed by the OOM killer. Could be unpleasant if you're writing an email or document that suddenly disappears because your app got killed.

Re: Stop making swap partitions—use swap files instead

#108

Post by binarin »

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?

With some workarounds, I've put chrome and slack into the same RAM-limited cgroup - no more whole system freezes. From my anecdotal evidence, this also answers the question "who should you kill" :)

Re: Stop making swap partitions—use swap files instead

#109

Post by [deleted] »

joshAg wrote: post #80
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?

Don't worry, it's not just you: https://lkml.org/lkml/2019/8/4/15 It's because linux is a toy OS. Specifically, it overcommits memory in the hope/assumption that it won't all be used at once, but doesn't have a way to gracefully degrade when applications collectively want to use more memory(+swap) than it actually has. You can turn off overcommit, but applications are designed with the overcommitting feature in mind,…

[deleted]

Re: Stop making swap partitions—use swap files instead

#110

Post by p_l »

jenders wrote: post #52
Kim_Bruning wrote: post #48

Earlier quoted context omitted.

Stop using LVM. Use ZFS! (ZFS might be described as the love child of lvm and btrfs, 'cept ZFS got there first) ( Very briefly: you hand ZFS a stack of disks (in mirrors or raidz groups, for redundancy) and it makes a zpool. Then you carve the pool into datasets as needed. Each dataset looks like an ordinary directory and takes only the space its files actually use, so you never guess partition sizes again. And each…

Not a btrfs user but OpenZFS u til recently didn’t even support O_DIRECT and may still duplicate page cache in arc. It’s not well suited as a general purpose FS where you can’t anticipate the workload, like on a desktop.

O_DIRECT is niche use case (originally called rather unkind words when it got copied from Irix to Linux).

Page cache duplication has been greatly lowered in last decade

Post reply on HN