From mboxrd@z Thu Jan  1 00:00:00 1970
From: Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH] drm/i915: protect force_wake_(get|put) with
 the gt_lock
Date: Mon, 7 Nov 2011 17:56:38 +0100
Message-ID: <20111107165638.GC4015@phenom.ffwll.local>
References: <1601723693.2108616.1320683984532.JavaMail.fmail@mwmweb005>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from mail-ww0-f43.google.com (mail-ww0-f43.google.com [74.125.82.43])
	by gabe.freedesktop.org (Postfix) with ESMTP id 392D99E817
	for <intel-gfx@lists.freedesktop.org>;
	Mon,  7 Nov 2011 08:55:38 -0800 (PST)
Received: by wwf4 with SMTP id 4so5818686wwf.12
	for <intel-gfx@lists.freedesktop.org>;
	Mon, 07 Nov 2011 08:55:37 -0800 (PST)
Content-Disposition: inline
In-Reply-To: <1601723693.2108616.1320683984532.JavaMail.fmail@mwmweb005>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=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: Nicolas Kalkhof <nkalkhof@web.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx <intel-gfx@lists.freedesktop.org>
List-Id: intel-gfx@lists.freedesktop.org

On Mon, Nov 07, 2011 at 05:39:44PM +0100, Nicolas Kalkhof wrote:
> Hi Daniel,
> 
> confirmed. Linus's linux-next.git shows the same behaviour. Until now
> I've used a patched 3.1-rc-6+ Kernel from Dave Airlie's branch
> (git://people.freedesktop.org/~airlied/linux' from Oct 26th.).
> dmesg/syslog shows nothing special, neither does i915_error_state.
> 
> Any advice?

If the behaviour-difference is clear, you could try to bisect this. The
alternative is to use your favourite system profiler and see where the
cycles get wasted (either sysprof or perf). I suggest you'll try whatever
approach your more familiar with first and then switch over to the other
if the first one doesn't yield any clear results. If the difference is
really clear, I'd start with the bisect (aside: don't restrict the bisect
to any subdir, the change causing the regression could equally likely be
somewhere in the core kernel).

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48