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