wakeup/sleep handoff.

[Stephan Uphoff]

On Wed, 2004-10-20 at 16:23, Julian Elischer wrote: 
> Stephan Uphoff wrote:
> 
> >On Tue, 2004-10-19 at 18:34, Julian Elischer wrote:
> >  
> >
> >>Is there a need to be able to somehow implement a 'wakeup_one()' that
> >>as part of its semantic is that the woken thread will run immediatly, 
> >>(as in preemprion),
> >>and the old thread will sleep? With preemption, the old thread is left 
> >>in the run queue,
> >>and after the other thread has completed, it will
> >>run again and probably go away and sleep for some reason.. (or at least 
> >>go do some work that isn't
> >>necessarily required..)
> >>
> >>Something like handover(wakeupchan, sleepchan, msleep_args...).
> >> sort of an atomic wakeup/msleep.
> >>
> >>This would be used in places where work used to be done by the same 
> >>thread, but is now done
> >>by a server thread..
> >>
> >>An example would be kicking off a geom thread, when in the past we would 
> >>have gone all
> >>the way down to the hardware ourself. we want to get as close to acting 
> >>like we are still
> >>going all the way done as we can (performance wise). We may get some 
> >>efficiency by
> >>letting the sleep system, and scheduler know what we are trying to do. 
> >>Possibly with some
> >>priority inherritance implications.. (if we have a high priority, we 
> >>probably want to ensure that the
> >>worker thread is run with at least that priority.)
> >>    
> >>
> >
> >Why not just give the geom thread a high priority?
> >This, full preemption and changing a few functions to guaranty that the
> >highest priority thread will always run should do what you want.
> >( And maybe always raising the priority of threads working in the
> >kernel)
> >Actually this is relatively high on my to do list and I should have some
> >patches to try out in a week or two.
> >
> 
> yessss but after the preemption (which is invisible to the caller of 
> setrunqueue/wakeup)
> that thread continues on to do it's "check for completion/sleep"..
> 
> it would be more efficient in my book to have an official way to hand 
> over to a designated worker
> all in one hit..  You could then optimise such cases.. They are often in 
> required fast-paths.

OK - I finally got it.

Maybe sections that temporarily disable preemption would do the trick.
Spinning on an adaptive mutex or blocking/sleeping should automatically
re-enable preemption.

On a related topic:
I don't like the way condition variables and msleep wait threads will be
scheduled on a wakeup - just to block again on trying to acquire a
mutex. However I don't see any way to avoid this that does not involve a
lot of work. Any idea beside not protecting the wakeup by a mutex?

Stephan