[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Overcommittable memory
On Tue, 21 Mar 2000, Helge Hafting wrote:

> > >Write the program without recursion and you know at compile-time how
> > >much memory it will ever need in the worst case.
> > >There is always at least one page - so make sure you use less than that.
> > >You'll need to know the stack overhead of any c-library you use - so
> > >don't use it or figure it out. It is doable with open-source libraries.
> >
> > TBH, I don't see the point. I know I have more than enough RAM to
> > handle most cases, and some extra swap for contingencies.
> >
> Someone mentioned how hard it was to write "memory safe" apps for
> embedded
> devices, considering how the stack is dynamically allocated. I pointed
> out
> that this isn't that hard.
> Having enough RAM is fine for a pc. An embedded device running linux
> will likely
> be mass-produced with the minimum amount of RAM though.

And no MMU and no swap space. They will never go OOS. No paging.
No processes killer. And why processes? Why a scheduler?

Besides that, why any embedded device should be optimized for high
multitasking - multiuser - general purpose workloads? That's what
"overcommitting" is for. That's what (vanilla) Linux is designed for.
Many parts of it are not well suited for embedded systems. They are not
designed for them.

____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.055 / U:3.528 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site