Date: Wed, 14 Jul 1999 16:49:57 -0600 From: Nate Williams <nate@mt.sri.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Nate Williams <nate@mt.sri.com>, cgd@netbsd.org (Chris G. Demetriou), freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <199907142249.QAA29554@mt.sri.com> In-Reply-To: <199907142245.PAA96901@apollo.backplane.com> References: <199907132110.OAA23817@lestat.nas.nasa.gov> <199907132114.OAA80781@apollo.backplane.com> <877lo4z0pe.fsf@redmail.redback.com> <199907132212.PAA81234@apollo.backplane.com> <871zecyx0k.fsf@redmail.redback.com> <199907142234.QAA29442@mt.sri.com> <199907142245.PAA96901@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> :> > 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907142249.QAA29554>