From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752558AbYJ0Pn3 (ORCPT ); Mon, 27 Oct 2008 11:43:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751210AbYJ0PnS (ORCPT ); Mon, 27 Oct 2008 11:43:18 -0400 Received: from mx3.mail.elte.hu ([157.181.1.138]:42555 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750866AbYJ0PnR (ORCPT ); Mon, 27 Oct 2008 11:43:17 -0400 Date: Mon, 27 Oct 2008 16:43:01 +0100 From: Ingo Molnar To: Frederic Weisbecker Cc: Steven Rostedt , Linux Kernel Subject: Re: [PATCH] [RESEND v2] tracing/ftrace: Introduce the big kernel lock tracer Message-ID: <20081027154301.GM5704@elte.hu> References: <48FF928F.1010300@gmail.com> <48FF93D1.4090008@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48FF93D1.4090008@gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00,DNS_FROM_SECURITYSAGE autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 DNS_FROM_SECURITYSAGE RBL: Envelope sender in blackholes.securitysage.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Frederic Weisbecker wrote: > diff --git a/lib/kernel_lock.c b/lib/kernel_lock.c > index 01a3c22..45828b2 100644 > --- a/lib/kernel_lock.c > +++ b/lib/kernel_lock.c > @@ -9,6 +9,7 @@ > #include > #include > #include > +#include > > /* > * The 'big kernel lock' > @@ -107,6 +108,37 @@ static inline void __unlock_kernel(void) > preempt_enable(); > } > > +#ifdef CONFIG_BKL_TRACER > +static void lock_kernel_trace(void) > +{ > + int cpu; > + struct bkl_trace_acquire trace; > + > + preempt_disable(); > + cpu = raw_smp_processor_id(); > + preempt_enable(); > + > + trace.acquire_req_time = cpu_clock(cpu); > + __lock_kernel(); > + trace.acquire_time = cpu_clock(cpu); > + trace_bkl_acquire(&trace); > +} > + > +static void unlock_kernel_trace(void) > +{ > + struct bkl_trace_release trace; > + trace.release_time = cpu_clock(raw_smp_processor_id()); > + trace_bkl_release(&trace); > + __unlock_kernel(); > +} > + > +#else > + > +#define lock_kernel_trace() __lock_kernel() > +#define unlock_kernel_trace() __unlock_kernel() > + > +#endif hm, this looks a bit ugly. are you aware of the tip/kill-the-BKL branch? It's an old-ish but otherwise sane branch that needs some refreshing (hence it's not part of tip/master). Once we have that "kill the BKL by turning it into a mutex" feature alive, and have fixed the places that rely on odd properties of the BKL, the BKL becomes just an ordinary mutex and we could trace its latencies via the existing lockdep/lockstat callbacks. and we could trace all the other mutexes as well. Ingo