[10000truths]

I'd be interested to see a Linux distribution whose entire shtick is to run well-behaved under a kernel with overcommit disabled. But it would be a huge undertaking. Besides the obvious issue with fork(), there are a lot of programs and libraries out there that implicitly rely on overcommit due to not checking malloc() for failure.

[man8alexd]

There is some kind of illusion or myth that strict overcommit solves memory management issues.

[silon42]

Not before userspace software is fixed, it doesn't.

[man8alexd]

You can't fix the fact that you can't predict the future. The software will always allocate more memory than it needs because it can't predict its future resource usage, so limiting memory allocation with strict overcommit is meaningless.

[silon42]

I disagree... it should not allocate much (like 2x) more than it needs right now...

(allocating virtual memory, but not committing is different, and should be handled with MAP_NORESERVE (or similiar)).

[zbentley]

Sigh. Malloc failure should have had to be trapped with a signal or something, not just a return status. I know, I know, threads and nesting handlers make that hard and historical precedent makes it impossible to retrofit, but I can still dream.