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
