3 ms·
Linux vm defaults are legit insane in 2026. - system dies under memory pressure (regardless of swapping, actually not having swap makes it worse which should b
by baq 3mo ago
Linux vm defaults are legit insane in 2026.
- system dies under memory pressure (regardless of swapping, actually not having swap makes it worse which should be common knowledge by now)
- system dies under disk pressure even if there are tons of free memory (this one is fun to diagnose)
- system can technically not die, but render itself useless (or worse) under memory pressure by the oom killer
- memory compression of any sort is not enabled
- ...
Both Windows and macOS do so much better out of the box for essentially any workload.
- koverstreet 3mo agoThe mm people are increasingly hostile to any method of handling OOMs (like, just failing the allocation) besides the OOM killer - it's become very dominated by the hyperscalars and cloud vendors. Working around mm nuttiness is a frequent source of frustration.
- layer8 3mo agomm?
- callahad 3mo agoI believe koverstreet is referring to the Linux kernel Memory Management subsystem (https://docs.kernel.org/mm/index.html https://docs.kernel.org/mm/index.html)
- deleted 3mo ago[deleted]
- cmurf 3mo agoKernel oomkiller is useless for the desktop. It only cares about kernel survival. There's user space oom options, like oomd, earlyoom ... but I'm not sure any heuristic really knows what user space program to clobber. Resource control via cgroupsv2 sounds better for both desktop and server use cases, differing by what processes receive minimum resources. But IO isolation remains elusive. Some suggest a database of hardware capabilities, I wonder if a cheap estimator of throughput and latencies could do this dynamically. Anyway, I'm not convinced user space should care about or rely on the kernel oomkiller. Well before it even considers the situation human interactivity with the system was lost.
- psd1 3mo ago> Well before it even considers the situation human interactivity with the system was lost. "Are you logged on to DB1?" "...yes?" "What did you do, it just died" This has happened multiple times
- man8alexd 3mo agoThere is no point in managing memory allocations as they have little relation to actual memory usage. There are also other methods than the OOM killer to handle OOM, like process throttling using cgroups "memory.high" limits.
- giancarlostoro 3mo agoYeah I noticed and was surprised after using ec2 that it didnt really have a sizable swap so it would lock up if I used enough memory importing a db export. Was genuinely surprised.
- pyinstallwoes 3mo agoWhat are better defaults for 2026+?
- baq 3mo agostart with a couple gigs of swap, fixed size sub-gig dirty buffers, enable zram, enable an oom daemon with some sane default configuration like 'kill X, wayland, sshd and shells last and browsers and node processes first' for some more user sanity huge ram consumers under memory pressure should be suspended, paged out as much as possible and the user notified (macOS does it right)
- alexrp 3mo ago> Both Windows and macOS do so much better out of the box for essentially any workload. We test FreeBSD, Linux, macOS, NetBSD, OpenBSD, and Windows in Zig's CI fleet. Of these, Windows is the only OS that we've had to configure with swap double the size of physical RAM to not hit completely unjustifiable OOMs. By "unjustifiable", I mean that we're not even close to actually running out of physical memory (let alone swap), but the MM seems to be doing a horrible job of making unused memory actually available to processes. It's possible there's a relevant configuration knob here that we're just not aware of... but the point is, the default behavior does in fact suck.