wakeup/sleep handoff.

Stephan Uphoff ups at tree.com
Tue Oct 19 19:00:42 PDT 2004


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.

	Stephan



More information about the freebsd-current mailing list