Re: Out of memory management in embedded systems

[Nicholas Miell <nmiell@comcast.net>]

On Fri, 2007-09-28 at 11:15 -0400, Rik van Riel wrote:
> 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.

SIGDANGER could stick useful information in siginfo_t's si_code field
and be delivered via a signalfd.

-- 
Nicholas Miell <nmiell@comcast.net>