From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 1/2] drm/i915: Remove use of the autoreported ringbuffer HEAD position Date: Wed, 8 Feb 2012 19:24:05 +0100 Message-ID: <20120208182405.GF5030@phenom.ffwll.local> References: <1328708054-26350-1-git-send-email-chris@chris-wilson.co.uk> <20120208145425.GD5030@phenom.ffwll.local> <867gzxfcrm.fsf@sumi.keithp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id 894AC9E730 for ; Wed, 8 Feb 2012 10:23:56 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so686475wgb.12 for ; Wed, 08 Feb 2012 10:23:55 -0800 (PST) Content-Disposition: inline In-Reply-To: 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 Wed, Feb 08, 2012 at 06:17:00PM +0000, Chris Wilson wrote: > On Wed, 8 Feb 2012 19:02:47 +0100, Daniel Vetter wrote: > > The issue is that the first one introduces a pretty decent perf > > regression, iirc Chris mentions something much large than 10x slowdown > > on certain cairo traces on sna. So we can only merge the first one > > together with the second one. > > As it turns out, the cairo-traces were successfully exploiting the > ringbuffer overflow to avoid work. The reason why it eventually broke is > that when I experimented with using the BLT and semaphores, I introduced > a dependency on accurate seqno processing, which was obviously broken by > the overwriting of commands in the ringbuffer. And so is consistent with > the hangs reported by Eugeni and Ben, but we have yet to see many more > examples in the wild. Otoh, I don't think this explains the > all-generation use-after-free bug. > > Net result, the 0.9s firefox-paintball result was a fantasy and the perf > gains provided by the second patch are only around 20% for the same > trace. Ergo -next material only if it passes scrutiny. Well, that explains a few things. In that case I'm fine with just merging the first patch for -fixes, I think there're quite a few bugs this does fix. -Daniel -- Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48