Messages in this thread | | | Date | Tue, 08 Dec 2009 09:31:26 +0800 | From | Xiao Guangrong <> | Subject | Re: [PATCH 2/2] perf lock: New subcommand "lock" to perf for analyzing lock statistics |
| |
Hi Frederic,
Frederic Weisbecker wrote:
> This profile has been done using ftrace with perf right?
We not use perf, just operate it by debugfs, the test procedure is like below:
case 1: disable all trace events: echo nop > debugfs/tracing/current_tracer echo > debugfs/tracing/set_event run benchmarks ...
case 2: enable all trace events except lockdep: echo nop > debugfs/tracing/current_tracer echo *:* > debugfs/tracing/set_event echo 0 > debugfs/tracing/events/lockdep/enable run benchmarks ...
> In one of your previous mails, you showed us the difference > of the size of perf.data by capturing either scheduler events > or lock events. >
It's not my work :-)
Thanks, Xiao
> And IIRC, the case of lock events resulted in a 100 MB perf.data > whereas it was a small file for sched events. > > The overhead in the pagefault and mmap latency could then > result in the fact we have much more events to save, walking > through much more pages in perf buffer, then faulting more often, > etc. > > Plus the fact various locks are taken in mmap and fault path, > generating more lock events. > > Just a guess... > > >
| |