Messages in this thread | | | Date | Sun, 25 Jul 2004 16:19:51 -0400 | From | Timothy Miller <> | Subject | Re: Another dumb question about Voluntary Kernel Preemption Patch |
| |
Lee Revell wrote: > On Wed, 2004-07-21 at 17:38, Timothy Miller wrote: > >>Lee Revell wrote: > > >>>My >>>understanding is that the kernel is already preemptible anytime that a >>>spin lock (including the BKL) is not held, and that the voluntary kernel >>>preemption patch adds some scheduling points in places where it is safe >>>to sleep, but preemption is disabled because we are holding the BKL, and >>>that the number of these should approach zero as the kernel is improved >>>anyway. >> >>That's confusing to me. It was my understanding that the BKL is used to >>completely lock down the kernel so that no other CPU can have a process >>get into the kernel... something like how SMP was done under 2.0. > > > Yes, I was incorrect. The vountary kernel preemption patch takes > sections that are non-preemptible (aka holding a spinlock) and that > would otherwise run for an unbounded time and adds logic to break out of > those loops, releasing any locks, in order to allow a higher priority > process to run. It is voluntary because even though you are in a > non-preemptible section you voluntarily release any locks and yield to a > higher priority process. It has nothing to do with the BKL as such. >
I'm guessing, then, that if you get preempted, then the function call to voluntarily preempt returns a value which tells you whether or not you got preempted, so that you know whether or not to clean up the results of having your locks broken? (ie. re-lock)
And how does the voluntary-preempt code know which locks to break? All of them?
Thanks.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |