Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759346AbXEUHub (ORCPT ); Mon, 21 May 2007 03:50:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755127AbXEUHuX (ORCPT ); Mon, 21 May 2007 03:50:23 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:53577 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754375AbXEUHuX (ORCPT ); Mon, 21 May 2007 03:50:23 -0400 Date: Mon, 21 May 2007 09:50:13 +0200 From: Ingo Molnar To: Bill Huey Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Jason Baron , Steven Rostedt Subject: Re: [PATCH] lockdep: lock contention tracking Message-ID: <20070521075013.GA9419@elte.hu> References: <1179657026.5915.10.camel@lappy> <20070521060446.GA4593@gnuppy.monkey.org> <20070521060828.GB20277@elte.hu> <20070521064150.GC4442@gnuppy.monkey.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070521064150.GC4442@gnuppy.monkey.org> User-Agent: Mutt/1.4.2.2i X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -2.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-2.0 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.1.7 -2.0 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2146 Lines: 58 * Bill Huey wrote: > On Mon, May 21, 2007 at 08:08:28AM +0200, Ingo Molnar wrote: > > To me it appears Peter's stuff is already a pretty complete solution on > > its own, and it's a whole lot simpler (and less duplicative) than your > > lockstat patch. Could you list the specific items/features that you > > think Peter's stuff doesnt have? > > First of all, this isn't an either/or kind of thing nor should it be > thought of in that way. why? Please be specific. > Precise file/function/line placement for one thing. [...] Have you looked at the output Peter's patch produces? It prints out precise symbols: dcache_lock: 3000 0 [618] [] _atomic_dec_and_lock+0x39/0x58 which can easily be turned into line numbers using debuginfo packages or using gdb. (But normally one only needs the symbol name, and we certainly do not want to burden the kernel source with tracking __FILE__/__LINE__ metadata, if the same is already available via CONFIG_DEBUG_INFO.) anything else? > [...] My stuff is potentially more extensible since I have other ideas > for it that really are outside of the lockdep logic currently. [...] what do you mean, specifically? > That's why I was hessitant to completely unify with lockdep in the > manner you suggested. i really need specifics. Currently i have the choice between your stuff: 17 files changed, 1425 insertions(+), 80 deletions(-) and Peter's patch: 6 files changed, 266 insertions(+), 18 deletions(-) and Peter's patch (if it works out fine in testing - and it seemed fine so far on my testbox), is smaller, more maintainable, better integrated and thus the clear candidate for merging into -rt and merging upstream as well. It's far cleaner than i hoped this whole lock-stats thing could be done based on lockdep, so i'm pretty happy with Peter's current patch already. Ingo - 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/