From owner-freebsd-arch Wed May 24 7:46: 9 2000 Delivered-To: freebsd-arch@freebsd.org Received: from berserker.bsdi.com (berserker.twistedbit.com [199.79.183.1]) by hub.freebsd.org (Postfix) with ESMTP id F068637BC6C for ; Wed, 24 May 2000 07:46:04 -0700 (PDT) (envelope-from cp@berserker.bsdi.com) Received: from berserker.bsdi.com (cp@localhost [127.0.0.1]) by berserker.bsdi.com (8.9.3/8.9.3) with ESMTP id IAA05589 for ; Wed, 24 May 2000 08:46:03 -0600 (MDT) Message-Id: <200005241446.IAA05589@berserker.bsdi.com> To: arch@freebsd.org Subject: Preemptive kernel on older X86 hardware From: Chuck Paterson Date: Wed, 24 May 2000 08:46:03 -0600 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 3) Drop support for 386. 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. 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. 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. 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. Some even thought supporting the original Pentium processors might not be required. 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'm not wed to the above at all, it is more to get discussion started than anything else. Then again, if no one complains, it is easier. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message