lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cfd9edbf0709281358k3f6307e8h4d2c131378645747@mail.gmail.com>
Date:	Fri, 28 Sep 2007 22:58:46 +0200
From:	"Daniel Spång" <daniel.spang@...il.com>
To:	"linux-os (Dick Johnson)" <linux-os@...logic.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Out of memory management in embedded systems

On 9/28/07, linux-os (Dick Johnson) <linux-os@...logic.com> wrote:
>
> On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote:
>
> > On 9/28/07, linux-os (Dick Johnson) <linux-os@...logic.com> wrote:
> >>
> >> On Fri, 28 Sep 2007, [iso-8859-1] Daniel Spång wrote:
> >>
> >>> On 9/28/07, linux-os (Dick Johnson) <linux-os@...logic.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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ