From: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
DRI Development <dri-devel@lists.freedesktop.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
Huang Rui <ray.huang@amd.com>,
VMware Graphics <linux-graphics-maintainer@vmware.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Daniel Vetter <daniel.vetter@intel.com>,
Christian Koenig <christian.koenig@amd.com>
Subject: Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
Date: Wed, 21 Aug 2019 14:47:45 +0200 [thread overview]
Message-ID: <45aaf1ba-e8b8-d92e-7ae2-39ed746ffa3a@shipmail.org> (raw)
In-Reply-To: <a9190400-2414-8d83-0f37-61eb0f16504a@shipmail.org>
On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> On 8/20/19 4:53 PM, Daniel Vetter wrote:
>> With nouveau fixed all ttm-using drives have the correct nesting of
>> mmap_sem vs dma_resv, and we can just lock the buffer.
>>
>> Assuming I didn't screw up anything with my audit of course.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>> Cc: Christian Koenig <christian.koenig@amd.com>
>> Cc: Huang Rui <ray.huang@amd.com>
>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>> Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
>> Cc: Thomas Hellstrom <thellstrom@vmware.com>
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c | 34 ---------------------------------
>> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +------------------------
>> include/drm/ttm/ttm_bo_api.h | 1 -
>> 3 files changed, 1 insertion(+), 60 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index 20ff56f27aa4..a952dd624b06 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
>> *bdev)
>> ;
>> }
>> EXPORT_SYMBOL(ttm_bo_swapout_all);
>> -
>> -/**
>> - * ttm_bo_wait_unreserved - interruptible wait for a buffer object
>> to become
>> - * unreserved
>> - *
>> - * @bo: Pointer to buffer
>> - */
>> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
>> -{
>> - int ret;
>> -
>> - /*
>> - * In the absense of a wait_unlocked API,
>> - * Use the bo::wu_mutex to avoid triggering livelocks due to
>> - * concurrent use of this function. Note that this use of
>> - * bo::wu_mutex can go away if we change locking order to
>> - * mmap_sem -> bo::reserve.
>> - */
>> - ret = mutex_lock_interruptible(&bo->wu_mutex);
>> - if (unlikely(ret != 0))
>> - return -ERESTARTSYS;
>> - if (!dma_resv_is_locked(bo->base.resv))
>> - goto out_unlock;
>> - ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
>> - if (ret == -EINTR)
>> - ret = -ERESTARTSYS;
>> - if (unlikely(ret != 0))
>> - goto out_unlock;
>> - dma_resv_unlock(bo->base.resv);
>> -
>> -out_unlock:
>> - mutex_unlock(&bo->wu_mutex);
>> - return ret;
>> -}
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> index 76eedb963693..505e1787aeea 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
>> vm_fault *vmf)
>> &bdev->man[bo->mem.mem_type];
>> struct vm_area_struct cvma;
>> - /*
>> - * Work around locking order reversal in fault / nopfn
>> - * between mmap_sem and bo_reserve: Perform a trylock operation
>> - * for reserve, and if it fails, retry the fault after waiting
>> - * for the buffer to become unreserved.
>> - */
>> - if (unlikely(!dma_resv_trylock(bo->base.resv))) {
>> - if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
>> - if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
>> - ttm_bo_get(bo);
>> - up_read(&vmf->vma->vm_mm->mmap_sem);
>> - (void) ttm_bo_wait_unreserved(bo);
>> - ttm_bo_put(bo);
>> - }
>> -
>> - return VM_FAULT_RETRY;
>> - }
>> -
>> - /*
>> - * If we'd want to change locking order to
>> - * mmap_sem -> bo::reserve, we'd use a blocking reserve here
>> - * instead of retrying the fault...
>> - */
>
> I think you should justify why the above code is removed, since the
> comments actually outlines what to do if we change locking order.
>
> The code that's removed above is not for adjusting locking orders but
> to decrease the mm latency by releasing the mmap_sem while waiting for
> bo reserve which in turn might be waiting for GPU. At a minimum we
> should have a separate patch with justification.
>
> Note that the caller here ensures locking progress by adjusting the
> RETRY flags after a retry.
And this last sentence also means we still can remove the wu-mutex when
the locking order is changed, since the chance of livelock is goes away.
IIRC only a single RETRY spin is allowed by the mm core.
/Thomas
>
> /Thomas
>
>
>> - return VM_FAULT_NOPAGE;
>> - }
>> + dma_resv_lock(bo->base.resv, NULL);
>> /*
>> * Refuse to fault imported pages. This should be handled
>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>> index 43c4929a2171..6b50e624e3e2 100644
>> --- a/include/drm/ttm/ttm_bo_api.h
>> +++ b/include/drm/ttm/ttm_bo_api.h
>> @@ -765,7 +765,6 @@ ssize_t ttm_bo_io(struct ttm_bo_device *bdev,
>> struct file *filp,
>> int ttm_bo_swapout(struct ttm_bo_global *glob,
>> struct ttm_operation_ctx *ctx);
>> void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
>> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo);
>> /**
>> * ttm_bo_uses_embedded_gem_object - check if the given bo uses the
>
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-08-21 12:47 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 14:53 [PATCH 0/3] RFC/T: dma_resv vs. mmap_sem Daniel Vetter
2019-08-20 14:53 ` [PATCH 1/3] dma_resv: prime lockdep annotations Daniel Vetter
2019-08-20 14:56 ` Koenig, Christian
2019-08-21 15:44 ` Daniel Vetter
2019-08-20 14:58 ` Chris Wilson
2019-08-21 15:54 ` Thomas Hellström (VMware)
2019-08-21 16:34 ` Daniel Vetter
2019-08-21 17:06 ` Thomas Hellström (VMware)
2019-08-21 18:11 ` Daniel Vetter
2019-08-21 18:27 ` Thomas Hellström (VMware)
2019-08-21 19:51 ` Daniel Vetter
2019-08-22 6:42 ` Thomas Hellström (VMware)
2019-08-22 6:47 ` Daniel Vetter
2019-08-20 14:53 ` [PATCH 2/3] drm/nouveau: slowpath for pushbuf ioctl Daniel Vetter
2019-08-20 14:53 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-08-20 15:16 ` Koenig, Christian
2019-08-20 15:21 ` Daniel Vetter
2019-08-20 15:34 ` Koenig, Christian
2019-08-20 15:41 ` Daniel Vetter
2019-08-20 15:45 ` Koenig, Christian
2019-08-21 12:40 ` Thomas Hellström (VMware)
2019-08-21 12:47 ` Thomas Hellström (VMware) [this message]
2019-08-21 14:09 ` Daniel Vetter
2019-08-21 14:27 ` Thomas Hellström (VMware)
2019-08-21 14:47 ` Daniel Vetter
2019-08-21 15:03 ` Thomas Hellström (VMware)
2019-08-21 15:14 ` Daniel Vetter
2019-08-21 15:19 ` Thomas Hellström (VMware)
2019-08-21 15:22 ` Daniel Vetter
2019-08-21 15:34 ` Thomas Hellström (VMware)
2019-08-21 15:07 ` Koenig, Christian
2019-08-21 13:16 ` Thomas Hellström (VMware)
2019-08-21 14:10 ` Daniel Vetter
2019-08-21 14:30 ` Thomas Hellström (VMware)
2019-08-21 14:42 ` Daniel Vetter
2019-08-21 15:33 ` [PATCH] " Daniel Vetter
2019-08-20 18:35 ` ✗ Fi.CI.CHECKPATCH: warning for RFC/T: dma_resv vs. mmap_sem Patchwork
2019-08-20 19:06 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-08-21 16:22 ` ✗ Fi.CI.CHECKPATCH: warning for RFC/T: dma_resv vs. mmap_sem (rev2) Patchwork
2019-08-21 16:47 ` ✗ Fi.CI.BAT: failure " Patchwork
2019-08-21 18:52 ` ✗ Fi.CI.BAT: failure for RFC/T: dma_resv vs. mmap_sem (rev3) Patchwork
-- strict thread matches above, loose matches on Subject: below --
2019-08-21 21:50 [PATCH 1/3] dma_resv: prime lockdep annotations Daniel Vetter
2019-08-21 21:50 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-10-21 14:50 [PATCH 0/3] dma_resv lockdep annotations/priming Daniel Vetter
2019-10-21 14:50 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-11-04 17:37 [PATCH 1/3] dma_resv: prime lockdep annotations Daniel Vetter
2019-11-04 17:38 ` [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved Daniel Vetter
2019-11-06 10:24 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45aaf1ba-e8b8-d92e-7ae2-39ed746ffa3a@shipmail.org \
--to=thomas_os@shipmail.org \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linux-graphics-maintainer@vmware.com \
--cc=ray.huang@amd.com \
--cc=thellstrom@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox