From owner-freebsd-arch Wed May 24 18:49:31 2000 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id D28E637BBBB; Wed, 24 May 2000 18:49:22 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id SAA09486; Wed, 24 May 2000 18:49:13 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp02.primenet.com, id smtpdAAABraass; Wed May 24 18:48:56 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA12472; Wed, 24 May 2000 18:48:57 -0700 (MST) From: Terry Lambert Message-Id: <200005250148.SAA12472@usr05.primenet.com> Subject: Re: Preemptive kernel on older X86 hardware To: msmith@FreeBSD.ORG (Mike Smith) Date: Thu, 25 May 2000 01:48:57 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), cp@bsdi.com (Chuck Paterson), arch@FreeBSD.ORG In-Reply-To: <200005250127.SAA03314@mass.cdrom.com> from "Mike Smith" at May 24, 2000 06:27:30 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I think the work required to build two kernels instead of one, and > > then CPU-testing in the loader to pick one, is really trivial. I > > think there are better approaches to the problem than this, but > > this is enough to throw out that idea entirely. > > Are the mutexes inlined, or are they all function calls? If the latter, > loading lock_smp.ko vs. lock_std.ko would be pretty trivial... 8) I expect that they are inlined. What would be the "NOP" overhead on a pipelined instruction cache? I suspect that it would be the overhead of loading the instructions themselves, and that most of these cases would be prefetched. You could also tag functions that used these things to go into a seperate section, and then load "586_critical_sections.ko" instead, which would also be pretty trivial. There are really a heck of a lot of ways to solve this problem, without going to "processor not supported". One I've been evilly considering is that the older processors lacking the instruction could simply take an instruction fault, and handle it in software, like the old uVAX II trying to run VAX 11/780 instructions that it didn't support in silicon (I think the CRC32 instruction was one such beast). A more salient FreeBSD example might be the FPU emulator... I will say, without direct comment on Chuck's other posts at this time, that his suggested method is the same as that used in SVR4.0.2 ES/MP and in Solaris until at least 2.4. Going to kernel preemption and making the FS and other code reentrant rin UnixWare (SVR4.2) resulted in the SMP kernel running 135% of the speed of the non-SMP prior kernel -- on _UP_ hardware. This was in Novell benchmarks that weren't published, to my knowledge. The one problem I have with data locking rather than critical sectioning is that it is seductive, and can not easily be made to scale well over 4 processors. Some of the new Intel stuff is supposed to have 4 processors per chip casing... so this is not totally satisfying to me. Sun avoids this on their hardware by using clustering software and (effectively) discrete hardware. 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-arch" in the body of the message