Hacker News Reader

Comment by baq | Hacker News Reader

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.

View on HN

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

Windows seems to work a lot better with a 16MB page file for whatever reason, just because it refuses to enable memory compression without it. Fucking stupid

My curiosity is piqued. What reason did you have to disable the page file?

128GB of system memory?

That might remove a reason to not do it

Am I missing some sort of common-sense explanation of why page files are so great? I have enough system memory that I shouldn't need to spill it to disk.

You have a lot of unused anonymous memory that is better swapped out and used as a file cache. Specifically for Linux swap, see https://chrisdown.name/2018/01/02/in-defence-of-swap.html

I don't understand how swap helps when you already have enough memory though. The article seems to say it's important to be able to swap out anonymous pages, but why? Especially when you aren't under memory contention? Just because memory isn't needed yet doesn't mean it's a benefit to get rid of it. It takes time to swap it to disk and then time to get it back. Why is that so important? Why would the kernel turn off things like compression otherwise? Makes no sense to me. No swap = punish the user by being less efficient on purpose? That's no argument for swap at all.

No, that's not the common sense you are missing ;-)

Your system your rules. But you twiddled a knob to appease your tweak imp, you didn't like the new behaviour, so you called it "fucking stupid". My experience is that the windows vmm is a very high quality component, so simple heuristics tells me PEBCAK.

I can think of two different possible reasons why memory compression might require a page file. Until you understand the technical reasoning, you don't know whether the design is stupid or clever. So taking a strong position is _eliding over a core tenet of wisdom_

> But you twiddled a knob to appease your tweak imp

I ran out of disk space because Windows decided my page file should suddenly be 64gb. With no space left to save my work, I found out there's no way to shrink the page file without rebooting. Of course the next thing I did was try to cast it off.

Maybe it was my skill issue for not expecting a sudden 64gb file there... or my skill issue for not choosing a nonzero size after?

That's a good reason, I might do the same. I certainly used to twiddle that setting trying to make space for Sim City 2000 on an 80MB disk.

I see a major footgun in memory compression that Linux doesn't care about - it'll just oomkill your shit, hence TFA. But footguns are not acceptable in mass-market software. Apple also removes them.

It's easy to look at the half-baked ui libraries and fucking Teams and fucking SharePoint and conclude that Microsoft engineers are stupid. But, for your interest: https://blogsystem5.substack.com/p/windows-nt-vs-unix-design

It might be shocking but so does Linux (though 16MB won’t cut it) and all other OSes

Windows will autogrow the page file (*swap file is separate from a page file in Windows; swap is exclusively for UWP apps) as needed.

It sounds like the application wanted to allocate contiguous regions of memory when none were available. That's a typical indicator of an 'early' OOM condition.

When will people learn?

NT is optimized, since day one, to swap.

This is a feature, not a bug.

> NT is optimized, since day one, to swap.

I'm not sure what point you're making here. Did you assume we had the page file disabled or something?

> This is a feature, not a bug.

OOMing when there's tens of gigabytes of unused memory is a feature...?

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

mm?

I believe koverstreet is referring to the Linux kernel Memory Management subsystem (https://docs.kernel.org/mm/index.html)

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

> 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

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

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

What are better defaults for 2026+?

start 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)

Reply on news.ycombinator.com