> 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:
>>
>>> 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.
>
> Not if its input is not known beforehand. Take a browser in a mobile
> phone as an example, it does not know at design time how big the web
> pages are. On the other hand we want to use as much memory as
> possible, for cache etc., a method that involves the kernel would
> simplify this and avoids setting manual limits.
>
> Daniel
>
