From owner-freebsd-smp Wed May 7 11:34:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA07230 for smp-outgoing; Wed, 7 May 1997 11:34:47 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA07223 for ; Wed, 7 May 1997 11:34:44 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA21813; Wed, 7 May 1997 11:30:42 -0700 From: Terry Lambert Message-Id: <199705071830.LAA21813@phaeton.artisoft.com> Subject: Re: Where to start SMP? To: davem@jenolan.rutgers.edu (David S. Miller) Date: Wed, 7 May 1997 11:30:42 -0700 (MST) Cc: terry@lambert.org, steve@visint.co.uk, freebsd-smp@FreeBSD.ORG In-Reply-To: <199705071726.NAA05360@jenolan.caipgeneral> from "David S. Miller" at May 7, 97 01:26:09 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Depends on whether the options are set with negative or positive > logic, and at what level they are wired in. Best case, they cause > the use of different contents of an existing function pointer and > are set at boot time. Worst case, they are an extra compare and > branch in a path. > > Wrong, best case they use self modifying code so there is zero cost. > Each call really points to a patch function, which takes the return > address and patches that call instruction to actually call the locking > function for the desired MODE. Therefore you eat the relocation cost > once per code path, it essentially dynamically links itself at run > time. > > Come on Terry, read the friggin' paper before becoming an instant > expert on how to do these things... Uh, what "friggin' paper"? We were talking about whether or not run-time configuration should be done in a generic SMP kernel, or if it should be compile time (making it non-generic). I hesistate to suggest self-modifying code without a better understanding of what has and hasn't been called at the time the -c option is processed by the running kernel. At the very lease, the console code is there, so at lest the time code is present -- which means you are past the point of using self-modifying code on the time stuff. Now the timer stuff is one of the run-time options we need to hack, which leaves your idea somewhat problematic... yes, it could be gotten around, but please read the code on how 'boot -c' operates before you condemn me for not going immediately for the self-modifying code. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.