Re: [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved

From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: "Thomas Hellström (VMware)" <thomas_os@shipmail.org>
Cc: Thomas Hellstrom <thellstrom@vmware.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@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 16:42:48 +0200	[thread overview]
Message-ID: <CAKMK7uFr0X-wj24j7tGc-AOZHx4Rvqwjax=rZ82ydgWNhFdZ9w@mail.gmail.com> (raw)
In-Reply-To: <d1574611-e51d-e08c-5305-175e0375813e@shipmail.org>

On Wed, Aug 21, 2019 at 4:30 PM Thomas Hellström (VMware)
<thomas_os@shipmail.org> wrote:
>
> On 8/21/19 4:10 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware)
> > <thomas_os@shipmail.org> 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(-)
> >>>
> >>>
> >>> +     dma_resv_lock(bo->base.resv, NULL);
> >> interruptible, or at least killable. (IIRC think killable is the right
> >> choice in fault code, even if TTM initially implemented interruptible to
> >> get reasonable Xorg "silken mouse" latency).
> > I think interruptible is fine. I chickend out of that for v1 because I
> > always mix up the return code for _lock_interruptibl() :-)
>
> :). IIRC I think the in-kernel users of fault() were unhappy with
> interruptible.  (GUP?), but I guess it's better to use a bulk change at
> some point if necessary.

We've been using interruptible since forever, returning
VM_FAULT_NOPAGE to get the signal handled and re-run. Seems to not
have pissed off anyone thus far. I think if we do this I'll do it as a
follow-up.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx