: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 - c...@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
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
