> :> >     Quite true.  In the embedded world we preallocate memory and shape
> :> >     the programs to what is available in the system.  But if we run out
> :> >     of memory we usually panic and reboot - because the code is designed
> :> >     to NOT run out of memory and thus running out of memory is a catastrophic
> :> >     situation.
> :
> :*ACK*  This is unacceptable in many 'embedded' systems.
> 
>     Don't confuse a watchdog panic from other conditions.  If the embedded
>     system software is supposed to deal with a low-memory condition and can't,
>     the failsafe is all that's left between it and infinity.
> 
>     The statement that the kernel's overcommit methodology somehow prevents
>     one from being able to build embedded systems on top of it is just plain
>     incorrect.  The embedded system is perfectly capable of implementing its
>     own memory management to avoid the filesafe provided by the kernel.

It is.  But, it's not the most effecient/effective way of doing it.
Sometimes it's best to let the 'kernel' do the things it does best, and
let the users worry about the things they do best.

The kernel manages memory alot more effeciently than any userland
process can do, so why not let it?

>     Most of the embedded work I've done -- mainly remote telemetry
>     units running with flash and a megabyte or so of ram -- panic and
>     reboot if they run out of memory.

Most of the work we've done wouldn't allow this, especially if we were
using an OS like FreeBSD with a fairly long bootup time.  Especially if
it can be avoided.

Yes, we could (and did) do our own memory management, but it seems to me
that the kernel has alot more information available to it and would do
it better than I could.  Then again, maybe I'm totally confused about
how the VM system 'does its thing', and in reality it's no better at it
than our code, just alot more complex for no reason. :) :) :)



Nate