From owner-freebsd-hackers Wed Jul 14 15:50:18 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id A8F6214E8F for ; Wed, 14 Jul 1999 15:50:05 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id QAA11499; Wed, 14 Jul 1999 16:49:58 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id QAA29554; Wed, 14 Jul 1999 16:49:57 -0600 Date: Wed, 14 Jul 1999 16:49:57 -0600 Message-Id: <199907142249.QAA29554@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: Nate Williams , cgd@netbsd.org (Chris G. Demetriou), freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Replacement for grep(1) (part 2) 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> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :> > 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