From: Frederic Weisbecker <fweisbec@gmail.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: LKML <linux-kernel@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Jens Axboe <jens.axboe@oracle.com>,
Jason Baron <jbaron@redhat.com>,
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>,
Tom Zanussi <tzanussi@gmail.com>,
Masami Hiramatsu <mhiramat@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: [GIT PULL] perf updates
Date: Sun, 9 May 2010 22:43:28 +0200 [thread overview]
Message-ID: <1273437818-8130-1-git-send-regression-fweisbec@gmail.com> (raw)
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(-)
next reply other threads:[~2010-05-09 20:43 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-09 20:43 Frederic Weisbecker [this message]
2010-05-09 20:43 ` [PATCH 01/10] perf lock: Add "info" subcommand for dumping misc information Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 02/10] perf: Cleanup perf lock broken states Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 03/10] perf: Humanize lock flags in perf lock Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 04/10] perf: Fix perf lock bad rate Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 05/10] perf lock: Always check min AND max wait time Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 06/10] tracing: Drop lock_acquired waittime field Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 07/10] tracing: Drop the nested field from lock_release event Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 08/10] tracing: Factorize lock events in a lock class Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 09/10] perf/live-mode: Handle payload-less events Frederic Weisbecker
2010-05-09 20:43 ` [PATCH 10/10] perf lock: Drop "-a" option from cmd_record() default arguments set Frederic Weisbecker
2010-05-10 5:10 ` [GIT PULL] perf updates Frederic Weisbecker
2010-05-10 6:46 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2019-09-26 20:06 Ingo Molnar
2019-09-26 23:00 ` pr-tracker-bot
2016-08-06 6:05 Ingo Molnar
2016-05-25 20:18 Ingo Molnar
2015-07-04 11:25 Ingo Molnar
2015-04-18 15:22 Ingo Molnar
2013-11-13 20:58 Ingo Molnar
2012-05-23 19:01 Ingo Molnar
2011-02-26 15:11 [PATCH v2] perf: Fix undefined PyVarObject_HEAD_INIT in python 2.5 Frederic Weisbecker
2011-03-04 0:38 ` [GIT PULL] perf updates Frederic Weisbecker
2011-03-04 7:10 ` Ingo Molnar
2010-06-08 20:13 Frederic Weisbecker
2010-06-08 21:13 ` Ingo Molnar
2010-05-25 13:45 Frederic Weisbecker
2010-04-14 15:59 Frederic Weisbecker
2010-04-04 14:36 Frederic Weisbecker
2010-04-04 14:42 ` Frederic Weisbecker
2010-04-04 19:02 ` Ingo Molnar
2010-04-05 9:56 ` Hitoshi Mitake
2010-03-05 21:55 Frederic Weisbecker
2010-03-10 14:28 ` Ingo Molnar
2010-03-03 6:54 Frederic Weisbecker
2010-02-27 18:25 [GIT PULL] Perf updates Frederic Weisbecker
2009-12-14 16:24 [GIT PULL] perf updates Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1273437818-8130-1-git-send-regression-fweisbec@gmail.com \
--to=fweisbec@gmail.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=jbaron@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.com \
--cc=xiaoguangrong@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).