cvs commit: src/sys/vm vm_zeroidle.c

[David Xu]

David Schultz wrote:

>On Mon, Nov 01, 2004, John Baldwin wrote:
>  
>
>>On Monday 01 November 2004 05:51 am, Alfred Perlstein wrote:
>>    
>>
>>>* Alan Cox <alc at cs.rice.edu> [041031 20:53] wrote:
>>>      
>>>
>>>>On Sun, Oct 31, 2004 at 07:13:17PM -0800, Alfred Perlstein wrote:
>>>>        
>>>>
>>>>>* Alan Cox <alc at FreeBSD.org> [041031 11:33] wrote:
>>>>>          
>>>>>
>>>>>>alc         2004-10-31 19:32:57 UTC
>>>>>>
>>>>>>  FreeBSD src repository
>>>>>>
>>>>>>  Modified files:
>>>>>>    sys/vm               vm_zeroidle.c
>>>>>>  Log:
>>>>>>  Introduce a Boolean variable wakeup_needed to avoid repeated,
>>>>>>unnecessary calls to wakeup() by vm_page_zero_idle_wakeup().
>>>>>>
>>>>>>  Revision  Changes    Path
>>>>>>  1.31      +9 -2      src/sys/vm/vm_zeroidle.c
>>>>>>            
>>>>>>
>>>>>Why not switch to a cv?
>>>>>          
>>>>>
>>>>Calling cv_signal repeatedly would be no better than calling wakeup()
>>>>repeatedly.  Either way, a Boolean variable is desirable to prevent
>>>>unnecessary calls.
>>>>        
>>>>
>>>Yah, I figured there would be something in the cv code to optimize
>>>the "no waiters" case.
>>>      
>>>
>>There is, though sometimes it might think there are waiters when there 
>>actually aren't any.
>>    
>>
>
>It doesn't look very optimized:
>
>	void
>	cv_signal(struct cv *cvp)
>	{
>	
>		sleepq_lock(cvp);
>		^^^^^^^^^^^^^^^^^
>		if (cvp->cv_waiters > 0) {
>			[...]
>		} else
>			sleepq_release(cvp);
>
>The mutex associated with the condition variable will be held on
>entry to both cv_wait() and cv_signal(), so why is the sleepqueue
>locked in the no waiters case?
>
>
>  
>
cv_wait and cv_signal have to pass a serialization point,
the serialization point is condition variable internal lock,
before testing cvp_waiters, the internal lock should be
locked,  otherwise you should be ready to hit the race
condition. It is legal to call cv_signal() without a locked
mutex.

David Xu