Re: Out of memory management in embedded systems

[Rik van Riel <riel@redhat.com>]

On Fri, 28 Sep 2007 16:36:34 +0200
Eric Dumazet <dada1@cosmosbay.com> wrote:

> On Fri, 28 Sep 2007 10:17:11 -0400
> Rik van Riel <riel@redhat.com> wrote:
> 
> > On Fri, 28 Sep 2007 10:04:23 -0400
> > "linux-os \(Dick Johnson\)" <linux-os@analogic.com> wrote:
> > > On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote:
> > > 
> > > > On 9/28/07, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
> > > >>
> > > >> On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote:
> > 
> > > >>> Some kind of notification to the application that the available memory
> > > >>> is scarce and let the application free up some memory (e.g., by
> > > >>> flushing caches), could be used to improve the situation 
> > 
> > > Any networked appliance can (will) throw data away if there are
> > > no resources available.
> > 
> > That is exactly what Daniel proposed in his first email.
> > 
> > I think his idea makes sense.
> 
> IBM AIX uses SIGDANGER, that kernel can raise in OOM conditions to warn
> processes that are willing to handle this signal (default action for the
>  SIGDANGER signal is to ignore the signal)

I suspect that SIGDANGER is not the right approach, because glibc
memory arenas cannot be manipulated from inside a signal handler.

Also, "nearly OOM" is not the only such signal we would want to
send to userspace programs. It would also be useful to inform
userspace programs when we are about to start swapping something
out, so userspace can discard cached data instead of having to
wait for disk IO in the future.

A unix signal cannot encapsulate two different messages, while
something like a "/dev/lowmem" device can simply be added into
the program's main poll() loop and give many different messages.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan