Hi,

Jukka Larja (roskakori2006.delete@this.gmail.com) on January 14, 2020 10:13 am wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 14, 2020 7:48 am wrote:
> > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 14, 2020 6:37 am wrote:
> > >
> > > There's always compromizes to make. Since OOM practically never happens during normal running (and would
> > > equally seldom be avoidable with any sensible tricks), My view of preparing for it is the same as with any
> > > (premature) micro-optimization. It doesn't hurt, but I wouldn't want to pay people much for doing it.
> >
> > Some things I'm just unwilling to accept. For example, I can accept software failing due
> > to OOM, but I can't accept software not failing gracefully (losing data, not informing user
> > of the problem in the same way it provides feedback of other error conditions, etc).
>
> I would think the same way if I thought OOMs are common occurrance. Since they aren't
> I'm thinking about them more like hardware failures. At some level, you have to be
> prepared for them, but spending much time on that doesn't usually make sense.
>
> > > > No (or not necessarily). For example, if there's 2 GiB of
> > > > RAM and 20 GiB of swap space; and software frequently
> > > > uses 1 GiB of data and rarely uses 21 GiB of data; then it will not be slow at all. Note that this is very
> > > > common for desktop users - e.g. multiple applications and/or multiple browser tabs, with large amounts of
> > > > data, that are left "running" (sometimes for days) where all the data isn't actually accessed.
> > >
> > > I have hard time seeing that as anything else but memory leak. In case of memory leak it doesn't
> > > matter what you do. You'll run out of any amount of physical and virtual memory, with or without
> > > overcommit (except that with overcommit one can leak huge amounts of untouched memory).
> >
> > I have a hard time seeing how anyone can consider it a memory leak. If the user opens 10 applications
> > and leaves 9 of them "running/idle" while they use one of them, then none of them are leaking any
> > memory (but 9 applications that are "running/idle" aren't actually using any of the memory).
>
> I've never had a system that had anything near 1-to-10 RAM/swap ratio and was running
> acceptably. I'll usually notice problems at about 1-to-2, with page file on SSD and around
> 1-to-3 it may already be hard to get enough done to kill the stuff. Unless it's just a
> memory leak, in which case most of the memory really never gets accessed again.
>
> So on theoretical level I don't consider it a memory leak, but if I see such
> a system, I do presume it has gone to that state due to memory leak.
>
> > > > A process releasing its own memory when (e.g.) it tries to allocate more and "mmap()" returns ENOMEM and
> > > > retrying (and succeeding); or cancelling whatever it wanted the extra memory for (and not anything else);
> > > > or providing feadback directly to user/s (e.g. a dialog box so the user immediately knows what happened
> > > > and doesn't have to go hunting for obscure logs); or giving the process a chance to save important data
> > > > to disk so that it's not lost; are all important "first steps" to making software suck less.
> > >
> > > You can't presume any of those actions will succeed, if the original memory allocation failed,
> > > unless you somehow know that the OS can do everything you ask without using any extra memory itself.
> > > Even if you free significant amount yourself, another process may be hogging it immediately. Actually,
> > > unless you are very careful, another thread in your own process may be hogging it.
> > >
> > > So basically you are doing complicated things (that will hardly ever get tested
> > > and will most likely be buggy anyway) and still can't guarantee a good outcome.
> >
> > You've implied that you're a software developer, and yet you think this is "complicated" and "untestable"?
>
> Not untestable, but in practice hardly ever tested, because OOMs practically never happen.
>
> Every game console requires us to handle out of disk space (and other user data write errors) in some sensible
> way.

If someone ignored the error during write then (later) crashed while trying to load data that wasn't correctly written, would you assume the software is stupid? Why is it stupid for one resource (disk) and "normal" for another resource (memory)?

> Even with ready made tools to simulate the problem, it's still a bitch to test, because it's very
> much out of the normal execution path. It never gets tested, except when someone spends time to do just
> that. Devkits never run out of disk space in any normal use. In practice, it's easier to get saving the
> data right than it is to handle the case when saving fails. Not because it's actually more complicated,
> but because the non-problematic saving gets tested couple of orders of magnitude more often.

Seems like it'd be trivial to pretend a write returned an error when it didn't.

> > > > They are not the last steps by any means. For example; the system can be augmented by
> > > > per process quotas, or cgroups, and/or by some kind of "low memory notifications" sent
> > > > out by OS (to ask process/es to release some amount of memory if they're able).
> > >
> > > I'm pretty sure all OSes offer APIs to ask for amount of available memory. I don't believe
> > > it matters that it's "pull" instead of "push".
> >
> > Having to constantly monitor the OS (rather than the OS notifying you)
> > would increase the hassle; especially for "otherwise idle" processes.
>
> It's pretty trivial to run a thread that polls the OS every now and then. What's hard is
> to do something when numbers look bad (and to know what bad looks like to start with).
>
> > > Most projects have better things to do.
> >
> > If most people were incompetent, would you make incompetence mandatory?
>
> No. But I would try not to waste time on features that require competence to use.
>
> (Not really sure what incompetence has to do with any of this. I don't consider
> people incompetent for not caring about handling OOM. I consider that a good,
> pragmatic engineering in about 99.9 % of cases, if not more.)

The problem is that allowing overcommit prevents all software from handling OOM, not just software that doesn't handle OOM. You are saying "I don't handle OOM, therefore nobody should be allowed to handle OOM". Why should my software be prevented from handling OOM correctly just because your software sucks?

Note: If someone calls "mmap()" and doesn't bother to check if it returned -1, then I do consider them incompetent. At a minimum I'd expect some kind of "fprintf(stderr, "Failed to mmap, reason: %sn", strerror(errno) );" where OOM is at least treated the same as any other error condition and not ignored.

- Brendan