Hacker News Reader

Comment by fc417fc802 | Hacker News Reader

> does anyone know why

In a nutshell, overcommit. It's more or less broken by design but it's also incredibly practical so pretty much everyone does it.

Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?

View on HN

Notably windows doesn't use overcommit, and degrades much more gracefully under memory pressure. The biggest tradeoff is the amount of disk space consumed by a page file that also has to reserve space for unused pages that have been allocated but never been swapped in. On linux you can turn overcommit off, but there's too much software written around the assumption that overcommit is on

Is that still the case today? Notably (IIUC) overcommit is required for certain security measures. I believe it was chromium that I noticed mmaping somewhere north of 1 TB of memory on startup so that it can do (again IIUC) something akin to ASLR internally.

On Windows you can achieve something like manual overcommit by calling VirtualAlloc with just MEM_RESERVE. That gives you a continuous space in your process's virtual address space, without actually backing it with any physical pages. Kind of like what a malloc does on linux

But where linux would automagically back those pages once you use them, Windows requires you to actually ask for those pages to be backed by something (physical memory or page file) by calling VirtualAlloc with MEM_COMMIT on the range you actually want to use

At a glance that seems like a much more sensible design. I guess it's dead in the water for posix on account of fork being CoW? This is quite the rabbit hole. I wonder if programming languages ought to be designed in such a way to accommodate a preemptive signal indicating allocation failure in place of a page fault? Rather than malloc returning null or etc.

> I guess it's dead in the water for posix on account of fork being CoW?

If that's the only issue, it's avoidable for most use cases. Lots of processes that fork are doing fork/exec to run a helper program. If they know they will do that and that they will be a large process, it's often useful to setup a fork/exec helper in early application startup.

However, there are some applications that use CoW more intentionally. Lock -> fork -> (unlock in parent / persist coherent snapshot in child) is a common pattern; I believe redis uses thst pattern and I've seen it mentioned in discussions about MMO servers. I believe postgres uses fork and CoW for transaction isolation ... but postgres also runs on Windows so there must be another way or I don't understand.

For the persist case, you could imagine some sort of flag to fork to allow overcommit and maybe even to let CoW requests stall in the parent rather than fail... the child is expected to do its work and exit in a limited time.

Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit. Systems with loads of RAM barely lose any storage to swap, but once they do get hit, they can get many gigabytes of swap space without user interaction. I believe macOS does it too, of course.

I'm sure there are many reasons why Linux can't do that by default, but it's a real shame.

I assume that's primarily because the stance of most distros would require something like that to be strictly opt-in. I don't know if it's possible to trigger a service based on overall swap usage? But given that the oom killer exists I don't see why it couldn't be trivially repurposed to add swap files on the fly.

> Windows also does a neat trick Linux lacks: automatically adding more swap, up to a limit.

Given that one can have swap files, and can also use LVM LVs for swap, and given that userspace OOM killers that work way better than the built in one -for some workloads- exist, I see no reason why you couldn't have this on Linux. This comment [0] mentions a project that claims to do just that -and seems to use swapfiles to do it-, but I don't have any experience with it.

FWIW, I did find the README by the original author [1] far more informative than the one written by the new maintainer.

[0] <https://news.ycombinator.com/item?id=49656129>

[1] <https://pqxx.org/development/swapspace/>

> Couple that with the fact that it's difficult bordering on impossible to correctly determine the culprit. If you've got 16 GB RAM and the user launches 3 processes each of which attempts to use 8 GB who should you kill?

In all cases, yes, in some cases no, you can make some heuristics for common use cases

For example, if I have 3 process hogs, on desktop I'd rather have my dev containers be killed, than anything I'm using.

Or on server, I'd rather have anything else but SSH/VPN software killed, because that's needed to debug the problem.

With some workarounds, I've put chrome and slack into the same RAM-limited cgroup - no more whole system freezes. From my anecdotal evidence, this also answers the question "who should you kill" :)

Reply on news.ycombinator.com