Re: Out of memory management in embedded systems

["Daniel Spång" <daniel.spang@gmail.com>]

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:
>
> > 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:
> >>
> >>> On 9/28/07, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
> >>>>
> >>>> 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
> >>>
> >>
> >> Any networked appliance can (will) throw data away if there are
> >> no resources available.
> >>
> >> The length of a web-page is not relevent, nor is the length
> >> of any external data. Your example will buffer whatever it
> >> can and not read anything more from the external source until
> >> it has resources available unless it is broken.
> >
> > And how do you determine when no resources are availabe? We are using
> > overcommit here so malloc() will always return non null.
> >
>
> A networked appliance using embedded software is not your daddy's
> Chevrolet. Any task that is permanent needs to allocate all its
> resources when it starts. That's how it knows how much there are,
> and incidentally, it doesn't do it blindly. The system designer
> must know how much memory is available in the system and how much
> is allocated to the kernel.
>
> The fact that you can give a fictitious value to malloc() is not
> relevant. If you don't provide resources for malloc(), like
> (ultimately) a swap file, then you can't assume that it can do
> any design work for you.
>
> 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. This could be
a set top box, a  video game console or a mobile phone that run
dynamic applications.

Actually this is not only about applications allocating an unknown
amount of dynamic memory. A similar situation could also appear when
we run an unknown number of applications at once, each allocating just
a static amount of memory and then later starts to touching it.

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.