[GIT PULL] perf updates

* [GIT PULL] perf updates
@ 2010-05-09 20:43 Frederic Weisbecker
  2010-05-09 20:43 ` [PATCH 01/10] perf lock: Add "info" subcommand for dumping misc information Frederic Weisbecker
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: Frederic Weisbecker @ 2010-05-09 20:43 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: LKML, Frederic Weisbecker, Hitoshi Mitake, Peter Zijlstra,
	Paul Mackerras, Arnaldo Carvalho de Melo, Jens Axboe,
	Jason Baron, Xiao Guangrong, Tom Zanussi, Masami Hiramatsu,
	Steven Rostedt

Ingo,

Please pull the perf/test branch that can be found at:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
	perf/test

I've already posted the new reordering patches.

Summary:

- Now the reordering works with any kind of raw sample flow. I
  know I already said that with the previous period based reordering,
  but now it seems to be true. I hope...

- Perf lock cleanups and improvements.

- Lock events cleanups

Now I observed we lose a lot of events with perf lock. It's just
that the flow can be so huge that perf record can't keep up with
the buffers, and the kernel often meets the buffer size limit.
Increasing the buffers size makes the things better but it's still not
enough.

In fact we have strong scalability problems that can be solved after
we reach the two following steps:

- I need to unearth the injection thing, so that I'll be able to reduce
the size of the lock events: putting the name in the lock_init event only
and only pass the address of the lock instance in the other lock events.

- Introducing "perf muliplex". The way perf record saves the events by
walking through every counters in a linear way is nice if you have a small
flow and few cpus. I did all my tests on an SMT 2 threads machine (Atom) and
it loses lots of lock events (even with 8192 pages per counters), due to the
huge flow, and this linear walking: the time you read a counter and write the
events to the file, another counter may have reached its buffer size limit already.

Now I can imagine what will be the result after a test on this sparc machine
with 64 cpus.

So we need a perf record mode that does this: multiplex counters buffers per
cpu, so that we have one buffer per cpu. Having one thread per cpu that does its
own cpu record in its own file. Then pass the whole to perf multiplex that can
handle the multiplexing into a single file (useful as a multiplexing remote point
too for perf pipe).

Anyway, lot of work in prevision.

Thanks,
	Frederic
---

Frederic Weisbecker (9):
      perf: Introduce a new "round of buffers read" pseudo event
      perf: Provide a new deterministic events reordering algorithm
      perf: Cleanup perf lock broken states
      perf: Humanize lock flags in perf lock
      perf: Fix perf lock bad rate
      perf lock: Always check min AND max wait time
      tracing: Drop lock_acquired waittime field
      tracing: Drop the nested field from lock_release event
      tracing: Factorize lock events in a lock class

Hitoshi Mitake (2):
      perf lock: Add "info" subcommand for dumping misc information
      perf lock: Drop "-a" option from cmd_record() default arguments set

Tom Zanussi (1):
      perf/live-mode: Handle payload-less events

 include/trace/events/lock.h |   55 +++++-----------
 kernel/lockdep.c            |    4 +-
 tools/perf/builtin-lock.c   |  145 +++++++++++++++++++++++++++++++------------
 tools/perf/builtin-record.c |   34 +++++++---
 tools/perf/util/event.h     |    3 +-
 tools/perf/util/session.c   |  125 ++++++++++++++++++++++++++-----------
 tools/perf/util/session.h   |   36 ++++++-----
 7 files changed, 257 insertions(+), 145 deletions(-)

^ permalink raw reply	[flat|nested] 13+ messages in thread