Re: Overcomittable memory (Was: Linux 2.2.15pre12)

From: James Sutherland (jas88@cam.ac.uk)
Date: Mon Mar 13 2000 - 13:08:27 EST


On Mon, 13 Mar 2000, Khimenko Victor wrote:

> In <880.101T2300T1215172rask@kampsax.k-net.dk> Rask Ingemann Lambertsen (rask@kampsax.k-net.dk) wrote:
> > Den 06-Mar-00 23:53:26 skrev Stephen C. Tweedie fœlgende om "Re: Linux 2.2.15pre12":
>
> > ['hard' memory allocation policy]
>
> >> Your user space app uses all the memory it can and then gets ENOMEM on
> >> the next malloc. Fine.
>
> >> Then named does a malloc. It gets ENOMEM and dies,
>
> > That would be a very silly reaction to ENOMEM for a program like named.
> > The same goes for inetd, sendmail and init and other such programs.
>
> Feel free to cook up patches for few hundreds affected programs. Once you'll
> finish we can think about you approach again. Ok?
>
> P.S. You can all it any way you want but it's sad truth: syslogd, klogd, named
> and LOTS and LOTS of other daemons will die if malloc will return ENOMEM.
> Welcome to real world from your ivory tower :-)

More to the point, they will only call malloc() if they need more memory.
If they need it, and can't have it, then they are pretty much useless
anyway - cron won't be able to spawn any new processes (so might as well
exit), syslogd doesn't have the buffers to handle new entries (so might as
well exit) etc.

Basically, if you are OOM, the box is already hosed - anything we do after
that point should be considered last gasp triage, not a routine memory
handler strategy.

James.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:25 EST