One thing I obsess a little bit over is the fact that it’s 2026, we pretend that Linux is a serious OS, but we‘re still losing your data on a regular basis.

Out of memory conditions (OOM) are one of our biggest pain points, so I just did a quick experiment with macOS to see how they are handling OOM.

I loaded about 200 memory heavy tabs in Firefox and kept a close look at memory usage.

(1/4)

@verdre you can disable memory overcommitment I think? Never tried that, as I rarely have issues with OOM. But it should give processes an error when they try to malloc, which they then could handle.

@root42 @verdre I have not tested this thoroughly, but I believe that a hefty chunk of Linux's problems with swap thrashing are, at root, caused by its default heuristic that allows 20% of RAM to fill up with data that needs to get written to disk, before it actually starts making write() wait for the disk.

20% of RAM nowadays can easily be in the gigabytes. It takes at least a few seconds to flush all of that to even the fastest SSDs. But it takes only milliseconds to fill it up.

@root42 @verdre Swap thrashing went away forever for me when I started using these sysctl settings:

vm.overcommit_memory = 2
vm.overcommit_ratio = 95
vm.dirty_background_bytes = 16777216
vm.dirty_background_ratio = 0
vm.dirty_bytes = 67108864
vm.dirty_ratio = 0

which means no overcommit, reserve 5% of swap for root, start background writeback at 16 *megabytes* of dirty data and throttle writers at 64 megs

I'd love to work with someone on a proper study of whether this makes sense for everyone

@zwol Turning off overcommit is only viable when there's more than enough RAM and swap for all virtual memory allocations, so it isn't a safe default for everyone. However, in most cases it should be possible to make disabling overcommit viable by adding swap.

@root42 @verdre

@Changaco @root42 @verdre Yes, I always provision at least twice as much swap as RAM. I would *like* to also set resource limits that prevent any one process from consuming more than like 90% of total RAM but there currently isn't a good way to do that.

With today's disk sizes, the cost of reserving a few tens of gigs of disk to keep the kernel happy is almost always negligible. I *have* run into space problems with small VMs - but small VMs are where the OOM killer is most dangerous so I cope.