[Intel-gfx] [PATCH 1/3] drm/i915: Use a non-blocking wait for set-to-domain ioctl

[Daniel Vetter]

On Thu, Aug 23, 2012 at 01:12:51PM +0100, Chris Wilson wrote:
> The principal use for set-to-domain is for userspace to serialise
> operations with a particular buffer, for example to maintain coherency
> with a CPU map or to ratelimit its rendering by waiting on all previous
> operations before continuing. As such we tend to hold the struct_mutex
> for long periods during the synchronisation and so cause contention
> issues with other users of the graphics device, even for independent
> operations as memory management. An example is the contention between
> compiz and X which causes jitter in the display and a drop in peak
> throughput.
> 
> The ultimate solution would be a set of fine grained locks and lockless
> operations, but an intermediate step is to first attempt the
> synchronisation for set-to-domain without holding the mutex. This
> introduces a number of race conditions, so we limit it use to the ioctl
> periphery where we have no dependent state and can safely complete with
> a locked synchronisation afterwards.
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>

Can I have the "move functions around" patch split out, please?

Also, I think it doesn't make sense to splatter nonblocking bools all over
the code:
- We won't need such a dance anywhere else, since we require userspace to
  call set_domain before any cpu access anyway.
- I think hiding the mutex dropping deep down in the callchain is evil.

I.e. I'd prefer if we do the lock dropping in set_domain_ioctl itself and
just copy&pasta the required code to flush olr and whatnotelse. And since
we drop the mutex in between I actually think that the write domain
frobbery that wait_rendering does is positively harmful. But we don't need
it, so better cut it out (same applies to the retire_requests in there).
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48