scheduler (sched_4bsd) questions

[Julian Elischer]

can you run ktrdump against teh corefile and get the ktr output?
(you do have it enabled right?)


Peter Holm wrote:

>On Mon, Oct 04, 2004 at 01:34:38PM -0400, Stephan Uphoff wrote:
>  
>
>>On Mon, 2004-10-04 at 11:31, John Baldwin wrote:
>>    
>>
>>>On Friday 01 October 2004 12:13 am, Stephan Uphoff wrote:
>>>      
>>>
>>>>On Wed, 2004-09-29 at 18:14, Stephan Uphoff wrote:
>>>>        
>>>>
>>>>>I was looking at the MUTEX_WAKE_ALL undefined case when I used the
>>>>>critical section for turnstile_claim().
>>>>>However there are bigger problems with MUTEX_WAKE_ALL undefined
>>>>>so you are right - the critical section for turnstile_claim is pretty
>>>>>useless.
>>>>>          
>>>>>
>>>>Arghhh !!!
>>>>
>>>>MUTEX_WAKE_ALL is NOT an option in GENERIC.
>>>>I recall verifying that it is defined twice. Guess I must have looked at
>>>>the wrong source tree :-(
>>>>This means yes - we have bigger problems!
>>>>
>>>>Example:
>>>>
>>>>Thread A holds a mutex x contested by Thread B and C and has priority
>>>>pri(A).
>>>>
>>>>Thread C holds a mutex y and pri(B) < pri(C)
>>>>
>>>>Thread A releases the lock wakes thread B but lets C on the turnstile
>>>>wait queue.
>>>>
>>>>An interrupt thread I tries to lock mutex y owned by C.
>>>>
>>>>However priority inheritance does not work since B needs to run first to
>>>>take ownership of the lock.
>>>>
>>>>I is blocked :-(
>>>>        
>>>>
>>>Ermm, if the interrupt happens after x is released then I's priority should 
>>>propagate from I to C to B.  
>>>      
>>>
>>There is a hole after the mutex x is released by A - but before B can
>>claim the mutex. The turnstile for mutex x is unowned and interrupt
>>thread I when trying to donate its priority will run into:
>>
>>	if (td == NULL) {
>>			/*
>>			 * This really isn't quite right. Really
>>			 * ought to bump priority of thread that
>>			 * next acquires the lock.
>>			 */
>>			return;
>>		}
>>
>>So B needs to run and acquire the mutex before priority inheritance
>>works again and does not get a priority boost to do so. 
>>
>>This is easy to fix and MUTEX_WAKE_ALL can be removed again at that time
>>- but my time budget is limited and Peter has an interesting bug left
>>that has priority.
>>    
>>
>
>I'm not closer to being able to create this panic in a controlled way.
>After a whole day of different tests I finally got this panic:
>http://www.holm.cc/stress/log/cons81.html. The trigger seems to be one
>particular Java applet, but it is not easily reproduceable.
>
>- Peter
>
>  
>
>>>If the interrupt happens before x is released, 
>>>then the final bit of propagate_priority() should handle it since it resorts 
>>>the turnstile's thread queue so that C will be awakened rather than B.
>>>      
>>>
>>Agreed.
>>
>>	Stephan
>>    
>>
>_______________________________________________
>freebsd-arch at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-arch
>To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"
>  
>