Date: Wed, 24 May 2000 10:40:21 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Chuck Paterson <cp@bsdi.com> Cc: "Daniel C. Sobral" <dcs@newsguy.com>, arch@FreeBSD.ORG Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <200005241740.KAA76080@apollo.backplane.com> References: <200005241728.LAA07094@berserker.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:
:} 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
<dillon@backplane.com>
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?200005241740.KAA76080>