lkml.org 
[lkml]   [2008]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [RESEND v2] tracing/ftrace: Introduce the big kernel lock tracer

* Frédéric Weisbecker <fweisbec@gmail.com> wrote:

> 2008/10/27 Ingo Molnar <mingo@elte.hu>:
> >
> > * Frederic Weisbecker <fweisbec@gmail.com> 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 <linux/module.h>
> >> #include <linux/kallsyms.h>
> >> #include <linux/semaphore.h>
> >> +#include <trace/bkl.h>
> >>
> >> /*
> >> * 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.
>
>
> No problem, we can forget about it. My goal was to produce some
> statistics to locate the points that most often hold the bkl. That
> would help to define some priorities on which bkl holding is to
> remove first.
>
> But if that would be better to rather invest the time on the
> kill-the-bkl tree (which I thought was dead), so I would be pleased
> to help.

the kill-the-BKL tree is not dead, just inactive. Looking for a brave
volunteer to merge it up to latest, to boot it with
CONFIG_PROVE_LOCKING=y and to have a good look at all the BKL locking
output that lockdep might disable.

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/

\
 
 \ /
  Last update: 2008-10-27 19:31    [from the cache]
©2003-2011 Jasper Spaans