[PATCH] drm/amdgpu: Make amdgpu_bo_reserve use uninterruptible waits for cleanup

[Xie, AlexBin]

I just realised that there are some stress test that sends huge amount of signals. I used those tests in the pass 2 years...


-Alex Bin

________________________________
From: Christian König <deathsimple at vodafone.de>
Sent: Monday, May 1, 2017 10:28 AM
To: Xie, AlexBin; Michel Dänzer
Cc: amd-gfx at lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: Make amdgpu_bo_reserve use uninterruptible waits for cleanup

Am 01.05.2017 um 02:13 schrieb Xie, AlexBin:

On 28/04/17 11:12 PM, Xie, AlexBin wrote:

>> Am 28.04.2017 um 10:47 schrieb Michel Dänzer:
>>> From: Michel Dänzer <michel.daenzer at amd.com><mailto:michel.daenzer at amd.com>
>>>
>>> Some of these paths probably cannot be interrupted by a signal anyway.
>>> Those that can would fail to clean up things if they actually got
>>> interrupted.
>>>
>>> Signed-off-by: Michel Dänzer <michel.daenzer at amd.com><mailto:michel.daenzer at amd.com>
>>
>> Reviewed-by: Christian König <christian.koenig at amd.com><mailto:christian.koenig at amd.com>
>
> Alex X: Just a reminder: amdgpu_unpin_work_func is called by work queue.
> Signal is blocked already. un-interruptible waiting might slow thing
> down very slightly.

How so?

Alex X: I said "might". If you think it is not slower, it is fine for me.
My real concern is that the signals are blocked for work queue already. We don't need this change to avoid unnecessary risk.
In theory, I am not against this change.

I have to agree with that. For waits from work queues it is usually best to implicitly use un-interruptible waits for documentation purposes.

In other words even when we are sure that the code can't receive a signal we should write it conservatively.

Christian.


--
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer



_______________________________________________
amd-gfx mailing list
amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170502/f4977e67/attachment-0001.html>