From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/3] drm/i915: Use a non-blocking wait for set-to-domain ioctl Date: Fri, 24 Aug 2012 02:28:45 +0200 Message-ID: <20120824002845.GI5418@phenom.ffwll.local> References: <1345723973-22092-1-git-send-email-chris@chris-wilson.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id C0E219E7BF for ; Thu, 23 Aug 2012 17:28:22 -0700 (PDT) Received: by wgbdr1 with SMTP id dr1so822012wgb.12 for ; Thu, 23 Aug 2012 17:28:21 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1345723973-22092-1-git-send-email-chris@chris-wilson.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org 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 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@ffwll.ch Mobile: +41 (0)79 365 57 48