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

Xie, AlexBin AlexBin.Xie at amd.com
Tue May 2 14:35:49 UTC 2017

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.


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>

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

More information about the amd-gfx mailing list