From: Christoph Hellwig <hch@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: perf scripting
Date: Sat, 14 Aug 2010 16:04:15 -0400 [thread overview]
Message-ID: <20100814200415.GA24704@infradead.org> (raw)
In-Reply-To: <20100730140441.GB5269@nowhere>
On Fri, Jul 30, 2010 at 04:04:42PM +0200, Frederic Weisbecker wrote:
> I have the feeling you've made an ad-hoc post processing script that seems
> to rewrite all the format parsing, debugfs, stream handling, etc... we
> have that in perf tools already.
>
> May be you weren't aware of what we have in perf in terms of scripting support.
Frederic, any chance you could help me getting a bit more familar with
the perf perl scripting. I currently have a hacky little sequence that
I use to profile what callers generate XFS log traffic, and it like to
turn it into a script so that I can do a direct perf call to use it
to profile things without manual work, and generate nicer output.
Currently it looks like this:
perf probe --add xlog_sync
perf record -g -e probe:xlog_sync -a -- <insert actualy workload here>
then do
perf report -n -g flat
to get me the callchain in a readable format.
Now what I'd really like is a perl script that can read a file like
latencytop.trans (or just has the information embedded) which contains
functions in the backtrace that we're interested in.
E.g. one simple from the report command above may look like:
xlog_sync
xlog_write
xlog_cil_push
_xfs_log_force
xfs_log_force
xfs_sync_data
xfs_quiesce_data
xfs_fs_sync_fs
In which case I'm interested in xfs_log_force and xfs_fs_sync_fs. So
the output of the perl script should looks something like:
Samples Caller
2 xfs_fs_sync_fs
1 xfs_file_fsync
1 xfs_commit_dummy_trans
Or if I have a way to parse the argument of the probe (in the worst case
I can replace it with a trace event if that makes it easier):
Samples Flags Callers
1 sync xfs_fs_sync_fs
1 xfs_fs_sync_fs
1 sync xfs_file_fsync
1 sync xfs_commit_dummy_trans
next prev parent reply other threads:[~2010-08-14 20:04 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-30 13:36 [PATCH 0/6] Reduce writeback from page reclaim context V6 Mel Gorman
2010-07-30 13:36 ` Mel Gorman
2010-07-30 13:36 ` [PATCH 1/6] vmscan: tracing: Roll up of patches currently in mmotm Mel Gorman
2010-07-30 13:36 ` Mel Gorman
2010-07-30 14:04 ` Frederic Weisbecker
2010-07-30 14:04 ` Frederic Weisbecker
2010-07-30 14:12 ` Mel Gorman
2010-07-30 14:12 ` Mel Gorman
2010-07-30 14:15 ` Frederic Weisbecker
2010-07-30 14:15 ` Frederic Weisbecker
2010-08-14 20:04 ` Christoph Hellwig [this message]
2010-09-16 12:08 ` perf scripting Frederic Weisbecker
2010-09-17 10:32 ` Masami Hiramatsu
2010-09-18 5:04 ` Tom Zanussi
2010-07-30 13:36 ` [PATCH 2/6] vmscan: tracing: Update trace event to track if page reclaim IO is for anon or file pages Mel Gorman
2010-07-30 13:36 ` Mel Gorman
2010-07-30 13:36 ` [PATCH 3/6] vmscan: tracing: Update post-processing script to distinguish between anon and file IO from page reclaim Mel Gorman
2010-07-30 13:36 ` Mel Gorman
2010-07-30 13:36 ` [PATCH 4/6] vmscan: tracing: Correct units in post-processing script Mel Gorman
2010-07-30 13:36 ` Mel Gorman
2010-07-30 13:36 ` [PATCH 5/6] vmscan: Do not writeback filesystem pages in direct reclaim Mel Gorman
2010-07-30 13:36 ` Mel Gorman
2010-08-05 6:59 ` KOSAKI Motohiro
2010-08-05 6:59 ` KOSAKI Motohiro
2010-08-05 14:15 ` Mel Gorman
2010-08-05 14:15 ` Mel Gorman
2010-07-30 13:37 ` [PATCH 6/6] vmscan: Kick flusher threads to clean pages when reclaim is encountering dirty pages Mel Gorman
2010-07-30 13:37 ` Mel Gorman
2010-07-30 22:06 ` Andrew Morton
2010-07-30 22:06 ` Andrew Morton
2010-07-30 22:40 ` Trond Myklebust
2010-07-30 22:40 ` Trond Myklebust
2010-08-01 8:19 ` KOSAKI Motohiro
2010-08-01 8:19 ` KOSAKI Motohiro
2010-08-01 16:21 ` Trond Myklebust
2010-08-01 16:21 ` Trond Myklebust
2010-08-02 7:57 ` KOSAKI Motohiro
2010-08-02 7:57 ` KOSAKI Motohiro
2010-07-31 10:33 ` Mel Gorman
2010-07-31 10:33 ` Mel Gorman
2010-08-02 18:31 ` Jan Kara
2010-08-02 18:31 ` Jan Kara
2010-08-01 11:15 ` Wu Fengguang
2010-08-01 11:15 ` Wu Fengguang
2010-08-01 11:56 ` Wu Fengguang
2010-08-01 11:56 ` Wu Fengguang
2010-08-01 13:03 ` Wu Fengguang
2010-08-01 13:03 ` Wu Fengguang
2010-08-01 13:03 ` Wu Fengguang
[not found] ` <80868B70-B17D-4007-AA15-5C11F0F95353@xyke.com>
2010-08-02 2:30 ` Wu Fengguang
2010-08-02 2:30 ` Wu Fengguang
2010-08-02 2:30 ` Wu Fengguang
2010-08-05 6:45 ` KOSAKI Motohiro
2010-08-05 6:45 ` KOSAKI Motohiro
2010-08-05 14:09 ` Mel Gorman
2010-08-05 14:09 ` Mel Gorman
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=20100814200415.GA24704@infradead.org \
--to=hch@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.