Re: wakeup/sleep handoff.

On Tuesday 02 November 2004 10:12 am, Stephan Uphoff wrote:
> 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?

wakeup() and now cv_signal() and cv_broadcast() do not require the lock to be 
held, so I think that is the best approach.

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org