Brendan (btrotter.delete@this.gmail.com) on January 14, 2020 12:40 pm wrote:
>
> Sure, with an adequate amount of swap space those crashes simply wouldn't have happened.

It's easy to say "don't overcommit, just have enough swap space".

But it's wrong.

The thing is, it's easy to claim that overcommit is bad, but reality is often very very different. It's often horribly, horribly bad not to allow overcommit.

This is one of those places where some people think the world is black-and-white, and those people are just simply and utterly wrong. If you think that overcommit is bad, you simply don't know what you are talking about.

Overcommitting can be bad in some very specific circumstances. If you're doing hard realtime, or doing something truly safety-critical, and lives depend on it and nothing else matters, then yes, overcommit is bad.

But very few problems in engineering are of the kind where "nothing else matters".

Because engineering is about reality. And in reality, a lot of loads could end up using a lot more memory than they actually do. In reality, you have loads and loads of memory that ends up being shared, and committing to the theoretical case where all of them might need to become private copies is just a completely stupid waste of resources.

Resources that cost real money (or real opportunity) in reality.

In reality, a lot of memory ends up being stuff that you can throw out and re-generate even without swap, because it's a private file mapping that has never been written to - even if the process could have written to it. Maybe 5% of the mapped pages actually did get written to, and it's all mapped read-write because writing isn't wrong - it's just not common.

Do you commit to the "this could happen" case, or the "this is what seems to be actually happening" case?

And in reality, diskspace often isn't as cheap as people claim. You end up having other concerns, and while it's true that disk is much cheaper than RAM, it's not true that that means that you should just say "use 10x the diskspace of ram for swapspace, just in case", when in reality you don't need it.

There are also situations where people overcommit enormously. They are happily not nearly as common as they used to be: back in the bad old days of original Fortran, you often had absolutely enormous static allocations because your Fortran environment didn't have any real dynamic memory allocation capability, so you just sized your arrays for the worst case.

Yes, F77 is finally dead, dead, dead. I hope. But it lived on for a long time, and people used programs written for it for a long long time. And having one huge static array and just using the portion you needed was the thing people did. Really.

So if you then you run a much smaller problem on your desktop PC, you are really happy that the system is not being stupid and saying "you can't do that, because you don't have enough swap space".

See? It's not black-and-white. Sometimes overcommit is a bad idea. And sometimes not overcommitting is an equally bad idea.

End result: a good approach tends to be to "overcommit gently" by default, but allow people to set other policies (including that "overcommit wildly" for those old Fortan cases, but also "don't overcommit") if they have specific needs.

Because thinking the world is black-and-white in my opinion means that you shouldn't do engineering. Because you have a fundamentally incorrect world-view. There are basically zero real-world problems that have black-and-white answers. I think you'll find that even in "safety-critical" systems where peoples lives are at stake, you'll find that it's not really about "black-and-white", but often about "let's make the safety ranges 2-10x what we think they need to be".

Linus