> Your disk LED will be flashing incessantly (I'm not entirely sure why).

The VM is basically paging all clean pages in and out constantly as their tasks become runnable. A pretty standard case of thrashing.

This is with swap disabled.

It should have been clarified, because it is not obvious:

The kernel can evict memory-mappings of executable files which are currently running. When they jump to a part of the executable that is no longer in memory, it can page that part back in from the executable file on disk.

This is pretty cool. But when memory is very low, the kernel will evict practically all user-space executable mappings from memory, and will be reading back in and evicting back out executable file contents on practically every single context switch. It's just trying so hard to squeeze out some space to make its tasks fit in memory and complete successfully.

I think this was the desired behavior of big-iron batch-processing in the 90s? Not sure why it has persisted so long. I'm a big fan of linux and this is my biggest pet-peeve.

What's the other option, though? It gets a fault for a page somewhere, it needs memory, and it has none. You have to evict something. What's your choice if not swap or filesystem-backed pages?

Systems have never operated well under true VM pressure. Not in the 90's, not now. When the working set goes beyond available memory performance falls off a cliff.

And the report in the article doesn't seem to have a good comparison anyway. I mean, do we seriously believe that Windows or OS X can handle this condition (4G, no swap) better? I mean, swap is default for a reason.

I'd much rather have OOMkiller trigger than have my system sit completely unresponsive for huge chunks of time, while I slowly struggle to kill something.

While this might add convenience when all you do is use a web browser, Linux is huge in the server space. Having the OS suddenly and somewhat unpredictability killing programs is absolutely not an option for most workloads.

The oom killer already exists on servers and already can kill programs.

If you want to turn off overcommit and have the system power off when it runs out of memory, the kernel allows that.

Whatever knob they add will certainly be configurable, and ubuntu desktop can configure it one way while ubuntu server configures it the other, if it turns out people would prefer that.

In practice, people running servers seem to want oom killers to kick in before the server barfs. One example of this is facebook's oomd [1]. I assure you, they're running that on their servers, not their web-browser-machines.

[1]: https://github.com/facebookincubator/oomd