All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.