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