Re: Another dumb question about Voluntary Kernel Preemption Patch

[Timothy Miller]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/