From owner-freebsd-arch Wed May 24 10:54:42 2000 Delivered-To: freebsd-arch@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8D07337BA04 for ; Wed, 24 May 2000 10:54:38 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA20309; Wed, 24 May 2000 13:54:34 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.9.3/8.9.1) id NAA22048; Wed, 24 May 2000 13:54:04 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 24 May 2000 13:54:03 -0400 (EDT) To: Chuck Paterson Cc: arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware In-Reply-To: <200005241446.IAA05589@berserker.bsdi.com> References: <200005241446.IAA05589@berserker.bsdi.com> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14636.5048.656520.901095@grasshopper.cs.duke.edu> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Paterson writes: > > The 386 processors do not support the locked exchange instruction. > For these systems the locked exchange can be replaced with roughly > a "cli, tst, cmp, branch, store, sti". > > The following are the obvious choices > > 1. Make two separate builds. > > 2. Add both sets of code to all macros and do > run time checks. The penalties are: > > a) doing the check on each mutex operation. > b) bigger kernel > c) since both sets of code will be spread through > out the kernel next to each other it is > reasonable to expect that running either > set of code will be using more cache lines than > they would if they existed alone. > > To add a little perspective there are currently around > 1300 locking operation in the BSD/OS kernel that would > be effected by this. This is really a guess, but when > all is said and done I would say BSD/OS will end up with > between 1700 and 2500. Kernel size seems like a non > issue, the number of extra cache lines used also seems > likely to be a non issue. So it seems like it really comes > down to adding the extra test which will be significant > compared to the actual mutex operation. > Maybe we can have our cake & eat it too: Its my understanding that Tru64 (nee Digital UNIX, nee OSF/1 alpha) removes SMP locks for UP operation by having the first lock call actually be a call to a function which checks the number of CPUs and then patches the caller to remove the call to itself, and possibly patch out the SMP lock calls on a single processor system. I believe that Peter Wemm has brought this up in the past. Would it be possible for the mutex macros to have a call like this which queried the CPU version & patched in either the locked exchange instructions or a call to a special routine for 386/486 cpus? If this isn't possible on an x86, please don't laugh too hard. I really don't know much about low-level x86 details. Cheers, Drew ------------------------------------------------------------------------------ Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: gallatin@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message