[Intel-gfx] [PATCH 7/9] drm/i915: stop using ttm_bo_wait

[Christian König]

Am 30.11.22 um 15:06 schrieb Daniel Vetter:
> On Wed, 30 Nov 2022 at 14:03, Tvrtko Ursulin
> <tvrtko.ursulin at linux.intel.com> wrote:
>> On 29/11/2022 18:05, Matthew Auld wrote:
>>> On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
>>> <tvrtko.ursulin at linux.intel.com> wrote:
>>>>
>>>> + Matt
>>>>
>>>> On 25/11/2022 10:21, Christian König wrote:
>>>>> TTM is just wrapping core DMA functionality here, remove the mid-layer.
>>>>> No functional change.
>>>>>
>>>>> Signed-off-by: Christian König <christian.koenig at amd.com>
>>>>> ---
>>>>>     drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++++++---
>>>>>     1 file changed, 6 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>>>>> index 5247d88b3c13..d409a77449a3 100644
>>>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>>>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
>>>>> @@ -599,13 +599,16 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
>>>>>     static int i915_ttm_truncate(struct drm_i915_gem_object *obj)
>>>>>     {
>>>>>         struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
>>>>> -     int err;
>>>>> +     long err;
>>>>>
>>>>>         WARN_ON_ONCE(obj->mm.madv == I915_MADV_WILLNEED);
>>>>>
>>>>> -     err = ttm_bo_wait(bo, true, false);
>>>>> -     if (err)
>>>>> +     err = dma_resv_wait_timeout(bo->base.resv, DMA_RESV_USAGE_BOOKKEEP,
>>>>> +                                 true, 15 * HZ);
>>>> This 15 second stuck out a bit for me and then on a slightly deeper look
>>>> it seems this timeout will "leak" into a few of i915 code paths. If we
>>>> look at the difference between the legacy shmem and ttm backend I am not
>>>> sure if the legacy one is blocking or not - but if it can block I don't
>>>> think it would have an arbitrary timeout like this. Matt your thoughts?
>>> Not sure what is meant by leak here, but the legacy shmem must also
>>> wait/block when unbinding each VMA, before calling truncate. It's the
>> By "leak" I meant if 15s timeout propagates into some code paths visible
>> from userspace which with a legacy backend instead have an indefinite
>> wait. If we have that it's probably not very good to have this
>> inconsistency, or to apply an arbitrary timeout to those path to start with.
>>
>>> same story for the ttm backend, except slightly more complicated in
>>> that there might be no currently bound VMA, and yet the GPU could
>>> still be accessing the pages due to async unbinds, kernel moves etc,
>>> which the wait here (and in i915_ttm_shrink) is meant to protect
>>> against. If the wait times out it should just fail gracefully. I guess
>>> we could just use MAX_SCHEDULE_TIMEOUT here? Not sure if it really
>>> matters though.
>> Right, depends if it can leak or not to userspace and diverge between
>> backends.
> Generally lock_timeout() is a design bug. It's either
> lock_interruptible (or maybe lock_killable) or try_lock, but
> lock_timeout is just duct-tape. I haven't dug in to figure out what
> should be here, but it smells fishy.

Independent of this discussion could I get an rb for removing 
ttm_bo_wait() from i915?

Exactly hiding this timeout inside TTM is what always made me quite 
nervous here.

Regards,
Christian.

> -Daniel