Re: Out of memory management in embedded systems

["Abhishek Sagar" <sagar.abhishek@gmail.com>]

On 9/29/07, Daniel Spång <daniel.spang@gmail.com> wrote:
> > An embedded system is NOT an ordinary system that happens to
> > boot from flash. An embedded system requires intelligent design.
>
> We might be talking about slightly different systems. I agree that
> systems that are really embedded, in the classic meaning often with
> real time constraints, should be designed as you suggests. But there
> are a lot of other systems that almost actually are ordinary systems
> but with limited memory and often without demand paging.

[snip]

> For those systems I think we need a method to dynamically decrease the
> working set of a process when memory is scarce, and not just accept
> that we "are screwed" and let the OOM killer solve the problem.

In certain cases, I guess it could be a problem in the embedded
environment. Especially while running general purpose applications
with carefully designed real-time tasks. An OOM in such a case is
unacceptable.

The whole problem looks like an extension of page frame reclamation in
user space. If the user application's cache was owned by the kernel
(something like vmsplice with SPLICE_F_GIFT?), and the application
managed it accordingly, then they could probably be brought under the
purview of kernel's memory reclamation. This would mean that
applications wouldn't need to be triggered on low memory, and leave
memory freeing to the kernel (simpler and uniform). Perhaps it is even
possible to do this in the kernel currently somehow...?

--
Abhishek Sagar

-
> 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/
-
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/