Re: holywar: malloc() vs. OOM

[Rich Felker <dalias@aerifal.cx>]

On Sun, Jul 24, 2011 at 10:25:33PM +0400, Vasiliy Kulikov wrote:
> Oh, I forgot one major detail - the kernel by default have memory
> overcommit enabled (sysctl vm.overcommit_memory=0).  It means that even
> [...]
> For overcommit disabled OOM graceful handling should be possible, but
> I'm not sure it is _guaranteed_ that memory allocated by brk() and
> mmap() will be really available in the future.

Any system without this guarantee is a TOY, nothing more. I'm aware
that the default sucks, but that's not an excuse to break things for
competent admins who know how to fix the default...

> So, yes, if the program guarantees that it gracefully handle OOM *for
> sure*, then the workaround is indeed a breakage.  But I'm sure such
> programs are hell rare.  BTW, do you know such programs, except DBUS? :)

Pretty much any decent httpd, sshd, database, etc. should handle OOM
just fine - rejecting any connections for which the necessary
allocation fails. Having the daemon crash and not accept further
connections after the OOM condition is over would be very bad
behavior. Of course DJB liked writing software that way and using a
secondary daemon to restart his daemons when they crash, but that's
really unprofessional... and you can certainly come up with
applications where it would be very bad to have to restart when
somebody OOM'd it - a multiplayer game server comes to mind...

> > A better solution might be to have a gcc option to generate a read
> > from the base address the first time a function performs arithmetic on
> > a pointer it has not already checked. This is valid because the C
> > language does not allow pointer arithmetic to cross object boundaries,
> > and this approach could be made 100% correct rather than being a
> > heuristic that breaks correct applications.
> 
> A good idea.  It would be interesting to show actual numbers of the
> slowdown.  However, most of the time it would be a slowdown for no
> actual gain.

Actually it might be a speedup since it would act like a prefetch...
:)

Rich