JonasMar 6

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)

Show threadroot42Mar 6
@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.
Show threadZack Weinberg

@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.

Mar 6 at 8:56pmWeb
Show threadZack WeinbergMar 6

@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

Show threadZack WeinbergMar 6
@root42 @verdre I don't tend to have a lot of heavy browser tabs open but I do regularly do big scientific calculations that need swap (for scale, the machine has 32G of RAM and 256G of swap) and it remains usable even when those calculations are grinding away
Show threadroot42Mar 6
@zwol I don’t get the browser tabs thing either, rocking some 7-12 year old Macs here running Linux, all with 8G of RAM. But I think the OOM is worse for servers and enterprise applications. If your DB gets killed for example. But then maybe, just maybe, you have other issues. On the desktop this has never hit me. But I don’t push my machines that hard, I guess. My M1 with 16G only goes OOM in macOS due to a Safari bug with patreon.com.
Show threadjon rMar 7
@zwol
This sounds like proper Phoronix material.
@root42 @verdre
Show threadZack WeinbergMar 7
@yala @root42 @verdre Uh. It has been my impression for many years that Phoronix is in the business of farming ad impressions, and doesn't publish anything worth reading. Is that inaccurate?
Show threadjon rMar 7
@zwol
I can't tell, I'm using an ad blocker. But they get a lot of hardware sent for free for testing, if that is of concern. But I like the overview on happenings in Linux land. I'm not so much into lwm.net and such.
At least Phoronix does extensive hardware testing and is focussed on Linux, not like many other publications, such as Tom's Hardware or so.
@root42 @verdre
Show threadCharly Coste 🇫🇷Mar 25

@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

Show threadZack WeinbergMar 25

@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.

Show threadjon rMar 7

@zwol
Actually I had this with a hard drive that writes 230 MB/s cached and between 1,5 and 9 MB/s constantly.

Even when the transfers were completed, of course they were not done, it took more than ten minutes to unmount the device, initiated right after finishing.
@root42 @verdre