Date: Wed, 24 May 2000 14:42:14 -0600 From: Chuck Paterson <cp@bsdi.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@freebsd.org Subject: Re: Preemptive kernel on older X86 hardware Message-ID: <200005242042.OAA09548@berserker.bsdi.com>
next in thread | raw e-mail | index | archive | help
At first I thought we fundamentally disagreed and now reading more, well I'm not sure. Sorry if I'm repeat that which is totally obvious. The first thing is that in a fine grained implementation threads really aren't protected from preemption by a lock. All the lock does is protect the thread from other processes trying to look at the same data. Doing mtx_enter() has no effect on blocking interrupts. This is only true for non spin locks, which really are the only thing used in "generic" kernel code. Not all of the mutex operations are added cost. They are at least partially offset by the cost of removing SPLS. Particularly if the SPLS turn into function calls. If a thread is running and is preempted by an interrupt thread such that thread may end up being put on a run queue. This typically does not happen, but can happen. If this happens it may not be the same thread that ends up running next. This results in a top half thread effectively being preempted by another top half thread. This all works just find in either the single or multi processor environment as long as all the locks stay in place. } I would not characterize this as 'biting the bullet'. Having a } preemptive kernel is unlikely to improve performance. Accept that better attention can be paid to scheduling priorities. But, yes in general this is true. } The only reason there might be preemption at all is to deal with } 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). If you don't change to the highest priority task on return from an interrupt this is true. Even if you don't normally do this, BSD/OS currently does not, it can happen in pathological cases where the running thread when the interrupt occurred get put a way on a run queue. the thread got suspended } 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. Yes the same locking used to protect threads from each other, or more correctly the data the thread may be accessing, protects from preemption. Actually it doesn't protect from preemption, it protects from it mattering. The point being is that the locking and not left out as I thought you where saying. Chuck 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?200005242042.OAA09548>