Re: wakeup/sleep handoff.

From: Julian Elischer <julian_at_elischer.org>
Date: Wed, 20 Oct 2004 13:23:42 -0700
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
>  
>
Received on Wed Oct 20 2004 - 18:23:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:18 UTC