Re: Another dumb question about Voluntary Kernel Preemption Patch

Timothy Miller
2004-07-25T19:53:14Z

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.