Date: Fri, 24 Mar 2000 19:47:32 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kris@FreeBSD.org (Kris Kennaway) Cc: tlambert@primenet.com (Terry Lambert), dcs@newsguy.com (Daniel C. Sobral), wes@softweyr.com (Wes Peters), mwlucas@blackhelicopters.org (Michael Lucas), advocacy@FreeBSD.org Subject: Re: New article Message-ID: <200003241947.MAA07990@usr09.primenet.com> In-Reply-To: <Pine.BSF.4.21.0003231730070.51855-100000@freefall.freebsd.org> from "Kris Kennaway" at Mar 23, 2000 05:35:08 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The legacy stuff, yes. I said so. :-) The kernel options... As I said > > > *some* as unavoidable. INVARIANTS? > > > > Get rid of all invariants. > > options INVARIANTS turns on enforcement of invariants in the kernel as a > debugging aid. I'm not sure how it could be done dynamically at load time > without building two versions of all the modules. Perhaps it should be > made mandatory, but the slight performance penalty associated with it > might be a turnoff. That's done at compile time, as a command line option. A debug kernel is an exceptional condition. I thought you were referring to "invariants", as in "not permitted to vary after compilation". > SMP/non-SMP is another case which has its conditional fingers in the > code. When you multiply all of the options together, having 2^n different > option combinations for each base module suddenly doesn't look so > attractive.. Right. So get rid of the things, and enable SMP support on all kernels. Yeah, this particular case might be overkill, but it's probably not: UnixWare actually got 30% faster on UP after the SMP support went in, since allowing the kernel to be reentrant made SMP-style locking mandatory on UP kernels, but the increase in concurrency more than made up for the overhead. This was in 1993/1994, BTW. There's no rational reason for hard coding things like the number of PCI busses, or anything else that can reduce functionality by virtue of being hard-coded (or even cause a panic, as in the mbuf case, even when there are resources available which could have been used to satify the request, instead of panic'ing). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003241947.MAA07990>