Subject: Re: Is the netBSD kernel Preemptible ?
To: None <tech-smp@netbsd.org, tech-perform@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-smp
Date: 06/14/2002 14:28:20
[ On Friday, June 14, 2002 at 09:30:02 (+0100), David Laight wrote: ]
> Subject: Re: Is the netBSD kernel Preemptible ?
>
> On Thu, Jun 13, 2002 at 08:41:15PM -0700, Matt Thomas wrote:
> > 
> > At 04:34 PM 6/13/2002, David Francheski wrote:
> > > 
> > > Can anybody tell me if the netBSD kernel itself is preemptible?
> > > By this I mean can a context-switch to a higher priority process
> > > occur while in kernel mode?
> > 
> > The kernel is not currently preemptible.
> 
> However once the SMP changes are incorporated any code that
> doesn't have a lock held has to be written as though it could
> be preempted (because what the other cpu can do is worse).
> 
> The SVR4 kernel was changed to allow preemption in the kernel
> at the same time as it was made SMP.

So, how exactly does an application level process go about the task of
preempting the kernel?

This whole concept seems backwards to me!  Certainly the kernel can
context-switch to a higher priority process while in kernel mode, but
only by deciding that it must do so.  In order to make this decision it
must run the scheduler code that figures out what processes are runnable
and which has the highest current priority (and which, if there are
several, it will run).

Perhaps a more meaningful question might have been more along the lines
of:  Does the NetBSD kernel preempt itself on clock ticks and run the
scheduler algorithm and if it decides a high-priority process is due
some cycles then can whatever was happening elsewhere in the kernel be
suspended in order to do a context-switch back up to that high-priority
process?

Personally I wouldn't think such a scheme would be viable unless there
were multiple symmetric processors so that the kernel thread(s) could
continue executing even while some high-priority process was returned
to.  Dropping _everything_ in the kernel to service clock ticks, and to
do so by running even some tiny portion of the scheduler code on every
clock tick, seems like it would be both too complex and too costly to
gain any realizable benefit in return.  Now a true microkernel should be
able to preempt kernel processes at any time and run any higher-priority
user process.....

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>