Re: Is the netBSD kernel Preemptible ?
[email protected] (Greg A. Woods)
| Newsgroups | gmane.os.netbsd.devel.smp |
|---|---|
| Organization | Planix, Inc.; Toronto, Ontario; Canada |
| Message-ID | <[email protected]> |
[ 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; <[email protected]>; <[email protected]>; <[email protected]> Planix, Inc. <[email protected]>; VE3TCP; Secrets of the Weird <[email protected]>