Keith Whitwell wrote:

>Thomas Hellström wrote:
>  
>
>>Keith Whitwell wrote:
>>    
>>
>>>Thomas Hellstrom wrote:
>>>  
>>>      
>>>
>>>> linux-core/drmP.h       |   13 +++-
>>>> linux-core/drm_bo.c     |   31 ++++++-----
>>>> linux-core/drm_fence.c  |  128 
>>>> +++++++++++-------------------------------------
>>>> linux-core/drm_lock.c   |    4 -
>>>>    
>>>>        
>>>>
>>>Thomas,
>>>
>>>Can you be more specific about the changes in drm_lock.c -- what is the 
>>>background there - the change doesn't seem related to the commit comment?
>>>
>>>Keith
>>>
>>>  
>>>      
>>>
>>Ah, OK, this one more or less slipped through.
>>I might need to revert that.
>>
>>In a situation where there are many processes waiting on the hardware 
>>lock, and one process grabs it, the lock will lose the CONTENDED flag, 
>>until one of the sleeping processes is woken up by a clock tick and 
>>sends the CONTENDED flag again. The process taking the lock will not 
>>call the kernel to wake up sleeping processes, and can retake the lock 
>>again without calling the kernel.
>>
>>This is not an ideal situation, and the change makes sure that the 
>>process taking the lock calls the kernel again to wake up any sleeping 
>>processes even if there are none available. This seems improve 
>>scheduling at the cost of some extra CPU when there are more than one 
>>DRI client.
>>    
>>
>
>Ah, interesting.  This sounds like the cause of some pretty 
>long-standing bad behaviour of dri locking where some contexts end up 
>being 'locked out' despite the dri lock being repeatedly grabbed and 
>released by a given process.
>
>Keith
>  
>
Yes. Hmm, Actually the sleeping processes will not wake up by clock ticks
since schedule() is called instead of schedule_timeout(), so the starvation
can potentially go on forever. That's probably why some window movement 
sometimes
seemed to wake a locked-out context.

Anyway, while the current code seems to fix the problem, the best fix is 
probably to add a sleeping process counter to the lock. That would avoid 
unnecessary kernel calls when the lock is released and there are no 
processes waiting.

Thomas

>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>--
>_______________________________________________
>Dri-devel mailing list
>Dri-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/dri-devel
>  
>




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to