Messages in this thread | | | Subject | Re: Out of memory management in embedded systems | From | Nicholas Miell <> | Date | Fri, 28 Sep 2007 16:00:39 -0700 |
| |
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>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |