Re: Another dumb question about Voluntary Kernel Preemption Patch

[Lee Revell <rlrevell@joe-job.com>]

On Sun, 2004-07-25 at 16:19, Timothy Miller wrote:
> Lee Revell wrote:
> > On Wed, 2004-07-21 at 17:38, Timothy Miller wrote:
> > 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?
> 

If we hit a voluntary preemption point and there is no higher priority
process ready to run, it's a NOOP, the code just continues without
breaking any locks.  If there is a runnable higher priority process,
then you have to release all spin locks to become preemptible.  This is
handled on a case-by-case basis, depending on what you have locked and
why.  When Ingo talks about points in the code being 'latency-aware'
this usually means in practice that we are iterating over some list that
could be very large, so one way to deal with it is to break out of the
loop and release the spinlock after N iterations, where N has to be
determined by benchmarking latencies.

Lee