Brendan (btrotter.delete@this.gmail.com) on January 11, 2020 10:15 pm wrote:
> Jukka Larja (roskakori2006.delete@this.gmail.com) on January 11, 2020 8:15 pm wrote:
> > Brendan (btrotter.delete@this.gmail.com) on January 11, 2020 9:14 am wrote:
> > >
> > > There's mostly 4 possibilities:
> > >
> > > a) Without over-commit, with swap space. In this case there's no real problem; and it's possible
> > > to end up with the perfect scenario - RAM full of "virtual memory that's actually used" and
> > > swap space just existing for "virtual memory committed to but not actually used".
> > >
> > > b) Without over-commit, without swap space. In this case most of the RAM ends
> > > up being wasted for "virtual memory committed to but not actually used".
> > >
> > > c) With over-commit, with swap space. In this case you the OS can commit to more virtual memory
> > > than it can provide (from RAM and swap) and you can end up screwed ("OOM killer").
> > >
> > > d) With over-commit, without swap space. In this case you the OS can commit to more virtual
> > > memory than it can provide (from RAM alone) and you can end up screwed ("OOM killer").
> >
> > From user point of view, I don't really see much difference in OOM-without-over-commit
> > and OOM-with-over-commit cases. Whether a process crashes when doing malloc or a bit
> > later when touching the allocated memory the first time doesn't really matter.
>
> From a process' perspective (or a programmer's perspective); there's a huge difference between random
> unexpected failure and (e.g.) "mmap()" returning an error that lets you free some virtual memory you
> were using elsewhere (e.g. for internally caching stuff) and retry (and maybe succeed), or lets you support
> "partial failure" (where one piece of work is aborted but all other work continues), or at least inform
> the user/log the problem so the user doesn't assume your software is a buggy piece of crap.

Sure. And I'm sure some programs make use of that. I'm not aware of any, though, so I presume it isn't very common. The random collection of scripts and utilities our build system runs doesn't even report OOM in any sensible way. Fortunately it is trivial to find out after the fact if that was the case (and like I said before, things slowing down once physical memory is getting too scarce is pretty good indicator that something is wrong).

-JLarja