lkml.org 
[lkml]   [2000]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcomittable memory (Was: Linux 2.2.15pre12)
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.182 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site