wakeup/sleep handoff.
Julian Elischer
julian at elischer.org
Wed Oct 20 13:23:43 PDT 2004
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.
>
> Stephan
>
>
More information about the freebsd-current
mailing list