Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754906Ab0BFQLG (ORCPT ); Sat, 6 Feb 2010 11:11:06 -0500 Received: from mail-ew0-f228.google.com ([209.85.219.228]:50177 "EHLO mail-ew0-f228.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753319Ab0BFQLE (ORCPT ); Sat, 6 Feb 2010 11:11:04 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=sIRIDeU6QwQajxiSJze8gikIqgcw4r7GM3YX4b6jfNUmhyCMA2CK0LzMiFDjx0uyNs 5ytZi7PgjwFzggotuRZqhaS+xj3hL9fSCG4nifC7NMG8OZ37ryX4BS7ETax1m/BCsR4Q L3CDBAhotd85sLeFOd1LNpQC9tZjTu65Div8U= Date: Sat, 6 Feb 2010 17:10:54 +0100 From: Frederic Weisbecker To: Peter Zijlstra Cc: Ingo Molnar , Lai Jiangshan , paulmck@linux.vnet.ibm.com, LKML , Arnaldo Carvalho de Melo , Steven Rostedt , Paul Mackerras , Hitoshi Mitake , Li Zefan , Masami Hiramatsu , Jens Axboe Subject: Re: [PATCH 10/11] tracing/perf: Fix lock events recursions in the fast path Message-ID: <20100206161052.GB5060@nowhere> References: <1265363102.22001.286.camel@laptop> <1265363441.22001.300.camel@laptop> <20100205104937.GB29515@elte.hu> <1265371808.22001.502.camel@laptop> <1265371973.22001.508.camel@laptop> <1265374915.22001.562.camel@laptop> <20100206111209.GC5062@nowhere> <1265455442.30057.499.camel@laptop> <20100206114046.GD5062@nowhere> <1265465867.30057.507.camel@laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1265465867.30057.507.camel@laptop> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1912 Lines: 42 On Sat, Feb 06, 2010 at 03:17:47PM +0100, Peter Zijlstra wrote: > On Sat, 2010-02-06 at 12:40 +0100, Frederic Weisbecker wrote: > > On Sat, Feb 06, 2010 at 12:24:02PM +0100, Peter Zijlstra wrote: > > > On Sat, 2010-02-06 at 12:12 +0100, Frederic Weisbecker wrote: > > > > > > > That said, I think this is good for a first step, but we can't continue > > > > to force the lock events -> lockdep dependency in the long term. We > > > > can't have a serious lock profiling if we are doomed to suffer the > > > > slowness due to lockdep checks at the same time. > > > > > > > > Sure we can continue to support having both, but I think we should also > > > > think about a solution to handle lock events without it in the future. > > > > That will require some minimal lockdep functionalities (keeping the > > > > lockdep map, and class hashes). > > > > > > You mean like building without CONFIG_PROVE_LOCKING, or boot with > > > lockdep.prove_locking=0, or use echo 0 > > > > /sys/modules/lockdep/prove_locking ? > > > > > > That keeps the lock tracking but does away with all the dependency > > > analysis and was created for just such an use case as you are looking > > > at, namely lockstat. > > > > > > Looks pretty what I'm looking for. Except that it still continues > > to fill and keep track of the locks held by the current thread, > > namely the copies in curr->held_locks. > > Which is exactly what you need for that lock hierarchy recording you > wanted :-) Well, the lock hierarchy should probably be retrieved from the traces, using state machines. Otherwise we would need yet other lock events for that, which is going to add even more overhead. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/