>
> On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote:
>
> > Applications with dynamic input and dynamic memory usage have some
> > issues with the current overcommitting kernel. A high memory usage
> > situation eventually results in that a process is killed by the OOM
> > killer. This is especially evident in swapless embedded systems with
> > limited memory and no swap available.
> >
> > 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 and avoid the
> > OOM killer. I am currently not aware of any general solution to this
> > problem, but I have found some approaches that might (or might not)
> > work:
> >
> > o Turn off overcommit. Results in a waste of memory.
> >
> > o Nokia uses a lowmem security module to signal on predetermined
> > thresholds. Currently available in the -omap tree. But this requires
> > manual tuning of the thresholds.
> >
http://www.linuxjournal.com/article/8502
> >
> > o Using madvise() with MADV_FREE to get the kernel to free mmaped
> > memory, typically application caches, when the kernel needs the
> > memory.
> >
> > o A OOM handler that the application registers with the kernel, and
> > that the kernel executes before the OOM-killer steps in.
> >
> > Does it exist any other solutions to this problem?
> >
> > Daniel
> > -
>
> But an embedded system contains all the software that will
> ever be executed on that system! If it is properly designed,
> it can never run out of memory because everything it will
> ever do is known at design time.
