Re: Out of memory management in embedded systems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2007-09-28 at 11:15 -0400, Rik van Riel wrote:
> On Fri, 28 Sep 2007 16:36:34 +0200
> Eric Dumazet <[email protected]> wrote:
> 
> > On Fri, 28 Sep 2007 10:17:11 -0400
> > Rik van Riel <[email protected]> wrote:
> > 
> > > On Fri, 28 Sep 2007 10:04:23 -0400
> > > "linux-os \(Dick Johnson\)" <[email protected]> wrote:
> > > > On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote:
> > > > 
> > > > > On 9/28/07, linux-os (Dick Johnson) <[email protected]> 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 <[email protected]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux