From: Chris Wilson <chris@chris-wilson.co.uk>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: "Daniel Vetter" <daniel@ffwll.ch>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Daniel Vetter" <daniel.vetter@ffwll.ch>,
"DRI Development" <dri-devel@lists.freedesktop.org>,
"Tiago Vignatti" <tiago.vignatti@intel.com>,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Daniel Vetter" <daniel.vetter@intel.com>,
linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
devel@driverdev.osuosl.org, "Hans Verkuil" <hverkuil@xs4all.nl>
Subject: Re: [PATCH] dma-buf: Update docs for SYNC ioctl
Date: Wed, 23 Mar 2016 11:56:59 +0000 [thread overview]
Message-ID: <20160323115659.GF21717@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <CANq1E4S4_vmCcPZJwpHkfOYuDe3boHCsYGW8q0U4=+tLui+QYg@mail.gmail.com>
On Wed, Mar 23, 2016 at 12:30:42PM +0100, David Herrmann wrote:
> My question was rather about why we do this? Semantics for EINTR are
> well defined, and with SA_RESTART (default on linux) user-space can
> ignore it. However, looping on EAGAIN is very uncommon, and it is not
> at all clear why it is needed?
>
> Returning an error to user-space makes sense if user-space has a
> reason to react to it. I fail to see how EAGAIN on a cache-flush/sync
> operation helps user-space at all? As someone without insight into the
> driver implementation, it is hard to tell why.. Any hints?
The reason we return EAGAIN is to workaround a deadlock we face when
blocking on the GPU holding the struct_mutex (inside the client's
process), but the GPU is dead. As our locking is very, very coarse we
cannot restart the GPU without acquiring the struct_mutex being held by
the client so we wake the client up and tell them the resource they are
waiting on (the flush of the object from the GPU into the CPU domain) is
temporarily unavailable. If they try to immediately wait upon the ioctl
again, they are blocked waiting for the reset to occur before they may
complete their flush. There are a few other possible deadlocks that are
also avoided with EAGAIN (again, the issue is more or less the lack of
fine grained locking).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: devel@driverdev.osuosl.org, Hans Verkuil <hverkuil@xs4all.nl>,
Daniel Vetter <daniel.vetter@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>,
Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
DRI Development <dri-devel@lists.freedesktop.org>,
linaro-mm-sig@lists.linaro.org,
Sumit Semwal <sumit.semwal@linaro.org>,
linux-media@vger.kernel.org
Subject: Re: [PATCH] dma-buf: Update docs for SYNC ioctl
Date: Wed, 23 Mar 2016 11:56:59 +0000 [thread overview]
Message-ID: <20160323115659.GF21717@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <CANq1E4S4_vmCcPZJwpHkfOYuDe3boHCsYGW8q0U4=+tLui+QYg@mail.gmail.com>
On Wed, Mar 23, 2016 at 12:30:42PM +0100, David Herrmann wrote:
> My question was rather about why we do this? Semantics for EINTR are
> well defined, and with SA_RESTART (default on linux) user-space can
> ignore it. However, looping on EAGAIN is very uncommon, and it is not
> at all clear why it is needed?
>
> Returning an error to user-space makes sense if user-space has a
> reason to react to it. I fail to see how EAGAIN on a cache-flush/sync
> operation helps user-space at all? As someone without insight into the
> driver implementation, it is hard to tell why.. Any hints?
The reason we return EAGAIN is to workaround a deadlock we face when
blocking on the GPU holding the struct_mutex (inside the client's
process), but the GPU is dead. As our locking is very, very coarse we
cannot restart the GPU without acquiring the struct_mutex being held by
the client so we wake the client up and tell them the resource they are
waiting on (the flush of the object from the GPU into the CPU domain) is
temporarily unavailable. If they try to immediately wait upon the ioctl
again, they are blocked waiting for the reset to occur before they may
complete their flush. There are a few other possible deadlocks that are
also avoided with EAGAIN (again, the issue is more or less the lack of
fine grained locking).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-03-23 12:13 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 20:02 [PATCH] dma-buf,drm,ion: Propagate error code from dma_buf_start_cpu_access() Chris Wilson
2016-03-19 10:09 ` [PATCH] dma-buf, drm, ion: " Daniel Vetter
2016-03-19 10:09 ` Daniel Vetter
2016-03-21 6:13 ` Sumit Semwal
2016-03-21 7:30 ` [PATCH] dma-buf: Update docs for SYNC ioctl Daniel Vetter
2016-03-21 7:35 ` Sumit Semwal
2016-03-21 7:40 ` Hans Verkuil
2016-03-21 7:50 ` Daniel Vetter
2016-03-21 7:50 ` Daniel Vetter
2016-03-21 7:51 ` Daniel Vetter
2016-03-21 7:53 ` Hans Verkuil
2016-03-21 12:26 ` David Herrmann
2016-03-21 12:26 ` David Herrmann
2016-03-21 17:14 ` Daniel Vetter
2016-03-21 17:14 ` Daniel Vetter
2016-03-23 11:30 ` David Herrmann
2016-03-23 11:56 ` Chris Wilson [this message]
2016-03-23 11:56 ` Chris Wilson
2016-03-23 15:32 ` David Herrmann
2016-03-23 15:42 ` Chris Wilson
2016-03-23 15:42 ` Chris Wilson
2016-03-28 19:42 ` Tiago Vignatti
2016-03-29 9:47 ` David Herrmann
2016-03-29 9:47 ` David Herrmann
2016-03-29 17:20 ` Tiago Vignatti
2016-03-21 13:16 ` Tiago Vignatti
2016-03-21 13:16 ` Tiago Vignatti
2016-03-21 13:13 ` [PATCH] dma-buf,drm,ion: Propagate error code from dma_buf_start_cpu_access() Tiago Vignatti
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=20160323115659.GF21717@nuc-i3427.alporthouse.com \
--to=chris@chris-wilson.co.uk \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=devel@driverdev.osuosl.org \
--cc=dh.herrmann@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hverkuil@xs4all.nl \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-media@vger.kernel.org \
--cc=marcheu@chromium.org \
--cc=sumit.semwal@linaro.org \
--cc=tiago.vignatti@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.