Date: Thu, 25 May 2000 01:48:57 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: msmith@FreeBSD.ORG (Mike Smith) Cc: tlambert@primenet.com (Terry Lambert), cp@bsdi.com (Chuck Paterson), arch@FreeBSD.ORG Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <200005250148.SAA12472@usr05.primenet.com> In-Reply-To: <200005250127.SAA03314@mass.cdrom.com> from "Mike Smith" at May 24, 2000 06:27:30 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005250148.SAA12472>