From: Frederic Weisbecker <fweisbec@gmail.com>
To: Jens Axboe <jens.axboe@oracle.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Steven Rostedt <rostedt@goodmis.org>,
Paul Mackerras <paulus@samba.org>,
Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
Li Zefan <lizf@cn.fujitsu.com>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Masami Hiramatsu <mhiramat@redhat.com>
Subject: Re: [PATCH 1/3] lockdep: Move lock events under lockdep recursion protection
Date: Wed, 10 Mar 2010 00:45:20 +0100 [thread overview]
Message-ID: <20100309234518.GE5058@nowhere> (raw)
In-Reply-To: <20100309083410.GD5768@kernel.dk>
On Tue, Mar 09, 2010 at 09:34:10AM +0100, Jens Axboe wrote:
> I went to try this on 2.6.34-rc1 to see how much it would improve things
> here. With 2.6.34-rc1, a
>
> $ time sudo perf lock record ls /dev/shm
>
> essentially hangs the box, it ends up crashing hard (not just live
> locked like before). With the patch in place, it does eventually finish:
>
> real 0m21.301s
> user 0m0.030s
> sys 0m21.040s
>
> The directory is empty.
Hehe :-)
That said you are probably missing a part of the puzzle.
This patch avoids the scary recursions we had. But there
is another separate patch that fixes the buffers multiplexing
dependency we had. Buffering is now done per cpu.
You need this patch:
commit b67577dfb45580c498bfdb1bc76c00c3b2ad6310
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date: Wed Feb 3 09:09:33 2010 +0100
perf lock: Drop the buffers multiplexing dependency
But this is not in -rc1, you need to checkout tip/perf/core
Well, the best would be you actually pull this on top of -rc1:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
perf/core
so that you get the buffers multiplexing dependency that is in -tip,
and you also get the recursions fixes, not yet in -tip (but should make
it soon).
I bet you still won't have magic results after that, but still it should
be better.
We still have further projects in mind to improve the scalability,
like the events injection thing (that avoids the string copy)
Again, you are my eyes on this, I'm still blind with my poor dual
laptop or my atom testbox.
Thanks for your testing.
next prev parent reply other threads:[~2010-03-09 23:45 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-03 6:54 [GIT PULL] perf updates Frederic Weisbecker
2010-03-03 6:55 ` [PATCH 1/3] lockdep: Move lock events under lockdep recursion protection Frederic Weisbecker
2010-03-09 7:18 ` Hitoshi Mitake
2010-03-10 0:10 ` Frederic Weisbecker
2010-03-09 8:34 ` Jens Axboe
2010-03-09 8:35 ` Jens Axboe
2010-03-10 0:05 ` Frederic Weisbecker
2010-03-10 15:45 ` Peter Zijlstra
2010-03-10 15:56 ` Jens Axboe
2010-03-10 15:55 ` Jens Axboe
2010-03-09 23:45 ` Frederic Weisbecker [this message]
2010-03-10 15:55 ` Jens Axboe
2010-03-03 6:55 ` [RFC][PATCH 2/3] perf: Take a hot regs snapshot for trace events Frederic Weisbecker
2010-03-03 8:38 ` Peter Zijlstra
2010-03-03 20:07 ` Frederic Weisbecker
2010-03-04 19:01 ` Frederic Weisbecker
2010-03-05 3:08 ` [PATCH 0/2] Perf " Frederic Weisbecker
2010-03-05 3:08 ` [PATCH 1/2] perf: Introduce new perf_save_regs() for hot regs snapshot Frederic Weisbecker
2010-03-05 15:08 ` Masami Hiramatsu
2010-03-05 16:38 ` Frederic Weisbecker
2010-03-05 17:08 ` Masami Hiramatsu
2010-03-05 17:17 ` Frederic Weisbecker
2010-03-05 20:55 ` [PATCH 1/2] perf: Introduce new perf_fetch_caller_regs() " Frederic Weisbecker
2010-03-05 20:55 ` [PATCH 2/2] perf: Take a hot regs snapshot for trace events Frederic Weisbecker
2010-03-05 3:08 ` Frederic Weisbecker
2010-03-03 16:06 ` [RFC][PATCH 2/3] " Steven Rostedt
2010-03-03 16:37 ` Peter Zijlstra
2010-03-03 17:07 ` Steven Rostedt
2010-03-03 17:16 ` Peter Zijlstra
2010-03-03 17:45 ` Steven Rostedt
2010-03-03 20:37 ` Frederic Weisbecker
2010-03-04 11:25 ` Ingo Molnar
2010-03-04 15:16 ` Steven Rostedt
2010-03-04 15:36 ` Ingo Molnar
2010-03-04 15:55 ` Steven Rostedt
2010-03-04 21:17 ` Ingo Molnar
2010-03-04 21:30 ` Steven Rostedt
2010-03-04 21:37 ` Frederic Weisbecker
2010-03-04 21:52 ` Thomas Gleixner
2010-03-04 22:01 ` Frederic Weisbecker
2010-03-04 22:02 ` Steven Rostedt
2010-03-04 22:09 ` Frederic Weisbecker
2010-03-03 6:55 ` [PATCH 3/3] perf/x86-64: Use frame pointer to walk on irq and process stacks Frederic Weisbecker
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=20100309234518.GE5058@nowhere \
--to=fweisbec@gmail.com \
--cc=acme@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/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