[PATCH v7 13/16] drm/scheduler: Fix hang when sched_entity released

Andrey Grodzovsky andrey.grodzovsky at amd.com
Wed May 19 11:51:12 UTC 2021



On 2021-05-19 7:46 a.m., Christian König wrote:
> Am 19.05.21 um 13:03 schrieb Andrey Grodzovsky:
>>
>>
>> On 2021-05-19 6:57 a.m., Christian König wrote:
>>> Am 18.05.21 um 20:48 schrieb Andrey Grodzovsky:
>>>> [SNIP]
>>>>>>
>>>>>> Would this be the right way to do it ?
>>>>>
>>>>> Yes, it is at least a start. Question is if we can wait blocking 
>>>>> here or not.
>>>>>
>>>>> We install a callback a bit lower to avoid blocking, so I'm pretty 
>>>>> sure that won't work as expected.
>>>>>
>>>>> Christian.
>>>>
>>>> I can't see why this would create problems, as long as the dependencies
>>>> complete or force competed if they are from same device (extracted) but
>>>> on a different ring then looks to me it should work. I will give it
>>>> a try.
>>>
>>> Ok, but please also test the case for a killed process.
>>>
>>> Christian.
>>
>> You mean something like run glxgears and then simply
>> terminate it ? Because I done that. Or something more ?
> 
> Well glxgears is a bit to lightweight for that.
> 
> You need at least some test which is limited by the rendering pipeline.
> 
> Christian.

You mean something that fill the entity queue faster then sched thread
empties it so when we kill the process we actually need to explicitly go
through remaining jobs termination ? I done that too by inserting
artificial delay in drm_sched_main.

Andrey

> 
>>
>> Andrey
>>
>>
>>>
>>>>
>>>> Andrey
>>>
>>> _______________________________________________
>>> amd-gfx mailing list
>>> amd-gfx at lists.freedesktop.org
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Candrey.grodzovsky%40amd.com%7Cce1252e55fae4338710d08d91ab4de01%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637570186393107071%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vGqxY5sxpEIiQGFBNn2PWkKqVjviM29r34Yjv0wujf4%3D&reserved=0 
>>>
> 


More information about the dri-devel mailing list