From owner-freebsd-arch Wed May 24 10:40:29 2000 Delivered-To: freebsd-arch@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 3A00637B743 for ; Wed, 24 May 2000 10:40:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA76080; Wed, 24 May 2000 10:40:21 -0700 (PDT) (envelope-from dillon) Date: Wed, 24 May 2000 10:40:21 -0700 (PDT) From: Matthew Dillon Message-Id: <200005241740.KAA76080@apollo.backplane.com> To: Chuck Paterson Cc: "Daniel C. Sobral" , arch@FreeBSD.ORG Subject: Re: Preemptive kernel on older X86 hardware References: <200005241728.LAA07094@berserker.bsdi.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : : :} Nobody is advocating scrapping the 386 for UP kernels. Even when/if :} the kernel becomes threaded, it still probably will not be preemptive :} but even if it were we are not going to be throwing cmpexg instructions :} in mainline *UP* code. If some of the imported code happens to do that, :} it's trivial to fix with #ifdef's for 386/486 support. : :This is actually not true (the nobody part). I'm afraid I have no :idea how to do a preemptive kernel where it doesn't diverge so :greatly that it won't be effectively a totally separate kernel. I :think if FreeBSD is not willing to bite the bullet on going to the :preemptive kernel then it just shouldn't get done. : :Chuck I would not characterize this as 'biting the bullet'. Having a preemptive kernel is unlikely to improve performance. The only reason there might be preemption at all is to deal wth interrupts. Interrupts currently preempt supervisor code. If interrupts are moved to interrupt threads then interrupt threads would need to be able to preempt supervisor code. In this fashion the supervisor thread would be preempted, but that is very different from having supervisor threads preempt other supervisor threads (something we probably will not do). The issues involved with kernel thread preemption are very similar to the issues involved with parallel kernel operation on an SMP system (something which we currently do not do for the most part due to the big giant lock). As pieces of the kernel become MP safe it will be possible to run more and more supervisor code in parallel on multiple cpu's. When that occurs the same locking used to protect those threads from each other will also make it possible to preempt kernel threads. Even with the capability, nobody I know who actually designs this stuff would ever contemplate actually *preempting* a kernel thread with another one (for non-interrupt threads, that is) -- there isn't a single benefit that would be gained from having the capability. The assembly used to implement the MP locks is irrelevant. We are not going to be strewing cmpexg instructions all over the code. If they exist anywhere itl will be in one or two low level assembly routines (such as i386/i386/mplock.s), and thus relatively trivial to conditionally compile based on the cpu (for either the UP or the SMP model). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message