lkml.org 
[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcommittable memory
Marco Colombo <marco@esi.it>:
> 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?

MMUs are getting too useful to leave out - even on printers. It makes
the setup, and data processing much simpler to program. Consider the
"lowly" disk drive - now there are disk drives that are actually small
computer systems (multi-processing, with scheduler) that take disk
commands and turn them into a high availability, raid drive.

Configuration and managment of the controler is/can be done over a
terminal or network connection. If done over the network, it can be
done via a browser.

I used to work on embeddes systems (real time navigation for seismic
surveys). These systems were usually installed on survey ships, and
sometimes in aircraft. As more and more functions were added to the
system, it became more and more failureprone (and we kept running out
of memory). We finally gave up on using an RT system without memory
management. It was just too difficult to isolate the bugs that kept
creeping in. We ended up using a RT system (with resource controls
too) just to get the system to function reliably. The MMU was used
to force isolation of function so that a failure of one function would
not invalidate the entire system.

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

I quibble about the "multiuser" aspect, but there are trends in the
industry to put web servers in a large number of network connected hardware.
Right now I'm putting disk controllers on a network so that a monitoring
workstation can run a web (in some form) based data collection for error
analysis of disk drives, controllers, and the entire fibre channel disk farm.

Guess what - I DONT want the controller to fail because there was a
burst of errors from the attached disks just because resources were allocated
for only one failure at a time (they never happen that often... I'm already
going through a muliple drive failure of that type... The customer is not
real happy about it either. At least the controller didn't fail... oops
its a windows based controller....:)

I don't care what OS the controler is running - I don't want it to fail
because it was overcommited...

I am getting a little too involved with this subject....
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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