Date: Thu, 25 May 2000 01:21:10 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: cp@bsdi.com (Chuck Paterson) Cc: arch@FreeBSD.ORG Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <200005250121.SAA11655@usr05.primenet.com> In-Reply-To: <200005241446.IAA05589@berserker.bsdi.com> from "Chuck Paterson" at May 24, 2000 08:46:03 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> 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". Jeffrey Hsu recently commented on this to me in regards to a paper by Michael Greenwald, in regard to having lock-free synchronized lists in the kernel. > The following are the obvious choices > > 1. Make two separate builds. This would be my choice: using a CPU type test in the loader in order to pick which kernel to load. Ideally, the kernel would be modular enough that this might degrade to the "load a different module as a replacement for a generic module" case. This would even work in the swap path, if it was adequately staged. Nice to get back to the "generic console driver" precepts from 1993... > Neither the 386 nor the 486 have a processor priority register or > cycle counters. Currently the BSD/OS SMPng kernel requires both of > these. There already exists some left over code to deal with not > having a cycle counter. Doing a casual inspection there really > doesn't seem to be anything too ugly in making the system run > without these when there is only a single processor. It would be interesting to know why the cycle counter was required, and how BSDI would deal with this on SMP Alpha and SPARC machines, or the new IBM 64 PPC processor NUMA machines... > I really don't know what BSDI will finally decided. I am confident > that we will not have run time checks in the locking operations. God forbid! > The argument, within BSDI, for supporting the older stuff is that > new embedded systems are being built with these processors. Raw > chip cost being the reason. While I believe the person telling me > this, I haven't personally seen the evidence, I haven't looked > either. You can buy external APICs for 486 based systems to achieve 486 SMP. This is where Intel SMP came from in the first place. The APICs went into the processor proper more to thwart third party processor manufacturers from creating SMP boxes using Intel APIC chips but not CPU chips, than anything else. My main rationale might be that there are a number of MEI coherency model SMP machines available, and likely to be built. Given the pricing on the PPC 603 chips, I think that a 603 PPC box based on the BeBox trick of replacing the L2 cache logic with discrete MEI logic, or even an external custom ASIC MMU that can use an L2 cache but still uses an MEI coherency modely would be likely. I can think of some pretty trivial embeded boxes that could be built on an ASIC, and would use multiple PPCs (maybe one for MPEG2 encoding?) based on the IBM "Blue Logic" PPC core component library. I think it is a bad idea to rule out PDAs and set-top boxes, entirely. > I have talked to a couple of people who think that supporting this > older stuff won't be important to FreeBSD by the time the kernel > is preemptive. This is a more important point. PEOPLE, THIS IS NOT STRICTLY AN SMP ISSUE! > Some even thought supporting the original Pentium processors might > not be required. This is just insane. As new processor migrate up Moore's law, the old processor cores will fall into embedded systems. IBM's recent announcement regarding SOI and CuSOI technologies should make people think twice about whether or not it's possible to upgrade old chips merely through a different set of fabrication technologies. > I'll propose the following as it reduces the work required: > > Once FreeBSD has a preemptive kernel FreeBSD will only run on > Pentium or better X86 processors. 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. Supporting loading of more segments, with segment attributes, is an obvious approach; Microsoft does this with VxD's and other NT and Windows kernel components, today. The only thing you have to worry about is being able to serialize access to the section being replaced (only during the replacement process) and not be in it when you flip the page table entry. You could even do defragmentation of the kernel address space, if you thought is was more useful than running on the new code and copying the new code to the old location, and then running there instead. 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?200005250121.SAA11655>