Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751050AbZLNF2M (ORCPT ); Mon, 14 Dec 2009 00:28:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750719AbZLNF2K (ORCPT ); Mon, 14 Dec 2009 00:28:10 -0500 Received: from casper.infradead.org ([85.118.1.10]:50478 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750705AbZLNF2J (ORCPT ); Mon, 14 Dec 2009 00:28:09 -0500 Date: Sun, 13 Dec 2009 21:30:15 -0800 From: Arjan van de Ven To: Frederic Weisbecker Cc: Ingo Molnar , Linus Torvalds , Thomas Gleixner , Alan Cox , Andrew Morton , Greg KH , Peter Zijlstra , linux-kernel@vger.kernel.org Subject: Re: [GIT PATCH] TTY patches for 2.6.33-git Message-ID: <20091213213015.653307b5@infradead.org> In-Reply-To: <20091213191606.GB7297@nowhere> References: <20091212101032.GB25286@elte.hu> <20091212023603.93768833.akpm@linux-foundation.org> <20091212214235.31429790@lxorguk.ukuu.org.uk> <20091213065844.GA20244@elte.hu> <20091213095534.58051536@infradead.org> <20091213191606.GB7297@nowhere> Organization: Intel X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; i586-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1775 Lines: 45 On Sun, 13 Dec 2009 20:16:08 +0100 Frederic Weisbecker wrote: > On Sun, Dec 13, 2009 at 09:55:34AM -0800, Arjan van de Ven wrote: > > On Sun, 13 Dec 2009 07:58:44 +0100 > > Ingo Molnar wrote: > > > > > > > > * Linus Torvalds wrote: > > > > > > > We've had quite a bit of BKL work this merge-window. Maybe we'll > > > > even get rid of it one of these days. There are "only" about 600 > > > > instances of "lock_kernel()" in the tree right now ;) > > > > > > I tend to use unlock_kernel() as the metric. (as it's more > > > precisely greppable and it is also more indicative of the > > > underlying complexity of locking, as it gets used more in more > > > complex scenarios) > > > > another metric is... how many times do we take the BKL for some > > workload. (For example booting or compiling a kernel). > > A counter like "BKLs-per-second" would be nice to expose > > (and then we can track that number going up as a regression etc) > > > > We have the bkl tracepoints for that, attaching an example below, > blkdev_get/bkldev_put is among the highest consumer for me. we have a trace, but not a number that anyone can just pull out without having to go through great lengths to set stuff up... (esp to capture a boot)... Adding a counter always to the lock_kernel function should be fine instead... -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/