:For some value of ultimate control.
:
:Reality these days is that if you want an embedded system based on
:UNIX that both doesn't suck and that has the features you need, you
:have to take _some_ off the shelf software components, glue them
:together as simply as possible, and do what you can to squeeze
:realiability out of them.
:
:There are many ways to squeeze reliability, with respect to memory
:consumption.
:
:One of them is hand-tuning resource limits for the applications, as
:you mention (and as I suggested in a previous e-mail).  However, this
:can be difficult to get right (but there's a safety margin), or, for
:some applications, impossible to do reasonably at all.
:
:You can attempt to deny it, but another valuable one is being able to
:detect without panic or without processes being killed that the system
:is out of memory, and the most sane way of doing that is with resource
:preallocation.  Yes, it's conservative, but there's no reliable
:alternative that i'm aware of.
:
:cgd
:-- 
:Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html

    Preallocate and touch (make dirty) all the memory you are going to use
    right off the bat.  Do not use recursive algorithms (guarentee the size
    of the stack), allocate memory out of fixed pools, put specific limits
    on all resources.  For example, allow only a certain number of TCP
    connections.

    Other alternatives (if you have a disk):  Do not use swap for backing 
    store.  Create a file in the filesystem, write it out (no holes), and
    mmap() it shared.  That can be your backing store.  Wire memory.  Have
    a watchdog to check whether you are getting close (free memory plus 
    available swap) to the machine's limits and signal the processes long
    before they would actually run out.

    There are a billion ways to do it and none of them require a swap
    reservation model.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>