Hi,

Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 15, 2020 2:33 am wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 14, 2020 1:58 pm wrote:
> > With overcommit, it's very hard.
>
> How so? Android is the only platform where checking that you're close
> to an OOM is trivial. On Windows it's really, really hard.
>
> > Without overcommit, anything that could cause OOM
> > will probably tell you immediately (ENOMEM in C, std::bad_alloc exception in C++,
> > OutOfMemoryError exception in Java, etc) which makes it fairly trivial to detect.
>
> If an allocation fails then it's way to late to do something about it.

No, you're assuming overcommit exists and its leading you to false assumptions.

If an allocation fails and there is overcommit; yes, you're probably screwed regardless.

If an allocation fails and there is no overcommit; then it's not a problem at all - you're able to do anything you like to handle that (without needing any notifications) without worrying about "OOM killer" preventing you from doing anything sane.

> Unless your software is completely
> trivial whatever failure path you have might need to allocate something - even only to inform other parts
> of the system that you ran out of memory - and that might fail too. You could also end up in a situation
> where some allocations fail and some succeed leaving objects in an incomplete state.

No, it's easy to pre-allocate whatever you need to handle errors like this (e.g. during process startup) to ensure you don't need to allocate when you can't. Sometimes that's not even necessary - in my case (server with one thread per connection) I can output to log without allocating and then terminate the thread/connection (which also causes its "thread local data" to be freed and helps other threads/connections avoid future allocation failures).

Of course if you do have overcommit, then things like modifying data or writing to a log file could cause "commited to but not actually allocated" pages to be allocated (and trigger "OOM killer"); so trying to handle OOM conditions does become a "tip-toe through the minefield" nightmare scenario that you've falsely assumed applies to "without overcommit".

> Show me code that
> handles that kind of scenario properly in a non-trivial application or I won't believe it exists.

https://stackoverflow.com/questions/45605806/out-of-memory-allocating-bytes

Note: "failed to allocate" was correctly handled by logging/reporting the error (instead of letting a random and potentially unrelated process get terminated by "OOM killer").

> > I'm sure "crash proof" will be a great comfort to the 100 pissed off customers
> > standing at the check-out lanes waiting for the point-of-sale system to work
> > because the back-end database went offline and needs time to restart. ;-)
>
> Unless you can come up with data that shows that systems that don't overcommit are
> less likely to go OOM than systems that do then those users are better served by the
> latter than the former. The data I have available points in the opposite direction.

You're being disingenuous by assuming a system without overcommit will be set up the same as a system without overcommit.

If you have one system that overcommits, and another system that doesn't overcommit but is given adequate swap space to ensure that it can handle the exact same load as the first system; then the only difference will be that the first system has "OOM killer" and may terminate unrelated processes (which is incredibly idiotic) and the second system will be able to handle OOM in whatever manner the developers wanted to (which can be significantly less idiotic).

The important thing is how OOM is handled, not how many cents worth of extra swap space are needed to avoid idiocy.

- Brendan