lkml.org 
[lkml]   [2000]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcommittable memory
On Tue, 21 Mar 2000, Jesse Pollard wrote:

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

Ok, sorry. Let me restate: no general-purpose MMU, no general-purpose
scheduler, like those of Linux are. Memory protection *is* useful, it
helps in debugging, and makes things stable. No wonder. Segments (the
80286 way), for example, are great for this purpose. But that's only
part of what the linux mm does. You don't need its complexity on
embedded systems. The same goes for the 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.
>
> 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.

That's their fault. They'll support that writing their own OS.
And, BTW, if they aim to put Apache on that hardware, i'll laught.

The Linux+Apache solution may be viable, as a low cost (they're there,
there're free) one. I've nothing against it. Until they start complaining
about that feature they want disabled because they don't like it
(but make perfectly sense on the main Linux+Apache use).

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

The controller won't fail because of overcommitment. It will fail (not
crash, BTW) because the programmers misunderstood the meaning of malloc().

> I am getting a little too involved with this subject....

Me too...

> -------------------------------------------------------------------------
> Jesse I Pollard, II
> Email: pollard@navo.hpc.mil
>
> Any opinions expressed are solely my own.

.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it


-
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.045 / U:0.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site