[olpc-software] graceful handling of out-of-memory conditions

Joshua N Pritikin jpritikin at pobox.com
Fri Mar 17 14:18:42 UTC 2006


On Fri, Mar 17, 2006 at 07:33:44AM -0500, Alan Cox wrote:
> On Fri, Mar 17, 2006 at 11:23:29AM +0530, Joshua N Pritikin wrote:
> > Wrap mmap, sbrk, and friends (via LD_PRELOAD or whatever).  If sbrk
> > finds that memory cannot be allocated then it writes the process ID
> > and the # of bytes to a UNIX domain socket a la ucspi-unix[1] and waits
> > for a policy decision.
> 
> It can't. It's out of memory. You just deadlocked.

How so? Does it cost memory to xfer through a unix domain socket? Can't
buffers be allocated in advance?

> Also a lot of out
> of memory situations arise from fork or exec so there is nothing to
> do the telling.

Granted but maybe the window manager knows what to do.

> This is important because it is possible to take some actions when available
> address space is low and the current totals are in /proc so can be monitored.
> So on out of memory we can't do a lot, something has to die that instant. On
> out of address space we can fail a malloc and if used carefully we can then
> flag that up to other code with care.

OK. I haven't studied the relevant LKML mailing list archives so I
hesitate to pursue this discussion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/olpc-software/attachments/20060317/047df0c4/attachment.sig>


More information about the olpc-software mailing list