Brendan (btrotter.delete@this.gmail.com) on January 13, 2020 7:21 am wrote:
> Hi,
>
> Jukka Larja (roskakori2006.delete@this.gmail.com) on January 13, 2020 6:41 am wrote:
> > Brendan (btrotter.delete@this.gmail.com) on January 12, 2020 9:19 pm wrote:
> > > anon (anon.delete@this.b.c) on January 12, 2020 11:30 am wrote:
> > > >
> > > > Even if you write your own code extremely carefully, unless you a programming in an embedded context
> > > > where you wrote all the code running on the platform, you can be pretty damn certain there is a
> > > > lot of other parts in your system that are not able to gracefully handle OOM. There are just no
> > > > server or desktop platforms in widespread use that can deal with OOM. It's entirely possible that
> > > > your program sucks up all the memory, and then OOM is triggered by some crucial background service
> > > > that nothing can live without, and which does not have viable alternatives to allocating.
> > > >
> > > > It's because of this that the sane option for desktop or server is to just ignore OOM and
> > > > pretend it doesn't exist. Just hardening your own software is the worst kind of idiocy
> > > > -- it's a massive waste of time, and it doesn't actually protect you from anything.
> > >
> > > This kind of thinking is the reason why the world sucks ("Some software is shit, therefore all software
> > > should be forced to be shit forever and nobody should ever try to make software better").
> >
> > This assumes there's an easy way to "make software better". Sure, if during large parallel
> > compile system runs out of memory, the compile can be restarted with less parallelism. And
> > when our custom game asset builder runs out of memory, just restart from some previous known
> > good state. Oh wait, that already happens when we just hit "Build" button again (or someone
> > makes an SVN commit and build system automatically start making a new build).
> >
> > OOMs are practically never a problem for us. Running with not-quite-enough-physical-memory is sometimes
> > a problem, but gets handled nicely by virtual memory. On average, we have plenty of RAM. Sometimes
> > various independent processes with large memory footprint just happen to run at the same time.
> >
> > If I had to come up with some manual system to handle the problem, I don't really see what I could
> > do to improve it. There could be some heuristics about available memory that would affect how much
> > parallel processes are launched. The problem is coming up with good heuristics. I have no idea how
> > much the shader compiler will need this time, or if it needs to run at all. There's hundreds of variables
> > to consider, each only making sense to couple of programmers in our thirty-ish member team.
> >
> > Virtual memory is by no means necessary to solve this problem easily. We have build
> > servers mostly configured with static page files, so as long as it is possible to
> > just add equivalent amount of RAM, the OOM problem will be solved just as well.
>
> Maybe the only thing you're thinking about is your build system,
> and the only people that care about your build system is you?
>
> Consider a HTTP server - do you want to (e.g.) drop one connection or abort
> one request, or do you want to get killed and drop all current connections?
>
> Consider a word processor - do you want to (e.g.) free memory from the "undo buffer" and retry
> (and if that doesn't work display a dialog box informing the user and save the current document
> and shut down gracefully); or do you want to get killed and lose all the user's unsaved work;
> or do you want kill X11 and screw up every single app that's currently running?
>
> How about a database management engine with 8 GiB of cached data it can easily discard - would you
> want everything that depends on it to suffer "sudden database un-availability" for no reason?

In my mind, it is "do I want those developers to fix some other bugs or spent their time on already well handled OOM problem?" Personally, I can't see what benefits of not having virtual memory could offset the benefits of having it.

If we have page file backed virtual memory, the examples you cite above won't happen that way. Instead you'll see gradual decrease in performance, which may get really bad before total failure (whether that's OOM or slowdown so bad that it disrupts the service, depends on virtual memory configuration).

The HTTP server example is actually really similar to our build server. If we wished, we could implement things so that only one operation or part of an operation fails due to OOM. But it makes no sense, since virtual memory solves the problem. And it works for all the operations and parts of them. And for future operations we (or some console manufacturer) add. And also for other stuff running on that server.

It's a nice idea that some process which holds large amounts of memory for caching purposes could release it when server starts to run out. But that doesn't really work on general purpose server. What if there are several independent processes, but they have different idea of what's the limit of "server starting to run out of memory"? The one with more relaxed limit won't free any of its cache before the other one has freed its.

-JLarja