From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>,
mingo@redhat.com, hpa@zytor.com, paulus@samba.org,
linux-kernel@vger.kernel.org, andi@firstfloor.org,
yakui.zhao@intel.com, fweisbec@gmail.com, ling.ma@intel.com,
rostedt@goodmis.org, miaox@cn.fujitsu.com, tglx@linutronix.de,
mingo@elte.hu
Subject: Re: perf monitoring triggers Was: Re: [tip:perf/core] perf bench: Print both of prefaulted and no prefaulted results by default
Date: Mon, 13 Dec 2010 11:12:18 -0200 [thread overview]
Message-ID: <20101213131218.GC5407@ghostprotocols.net> (raw)
In-Reply-To: <1292244059.6803.203.camel@twins>
Em Mon, Dec 13, 2010 at 01:40:59PM +0100, Peter Zijlstra escreveu:
> On Mon, 2010-12-13 at 10:38 -0200, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Dec 13, 2010 at 12:14:33PM +0100, Peter Zijlstra escreveu:
> > > Sounds to me like you want something like a library with self-monitoring
> > > stuff.
> > Yeah, that could be a way, an LD_PRELOAD thingy that would intercept
> > library calls, setup counters, start a monitoring thread, etc.
> > To make it easier we could move the counter setup we have in record/top
> > to a library, etc.
>
> Nah, I was more thinking of something along the lines of libPAPI and
> libpfmon. A library that contains the needed building blocks for apps to
> profile themselves.
Ok, you mean for the case where you can modify the app, I was thinking
about when you can't.
In both cases its good to move the counter creation, etc routines from
record/top to a lib, that then could be used in the way you mention, and
in the way I mention too. Two different usecases :-)
- Arnaldo
next prev parent reply other threads:[~2010-12-13 13:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-29 16:01 [PATCH 1/2] perf bench: port memcpy_64.S to perf bench Hitoshi Mitake
2010-10-29 16:01 ` [PATCH 2/2] perf bench: add x86-64 specific benchmarks to perf bench mem memcpy Hitoshi Mitake
2010-10-30 19:23 ` Ingo Molnar
2010-11-01 5:36 ` Hitoshi Mitake
2010-11-01 9:02 ` Ingo Molnar
2010-11-05 17:05 ` Hitoshi Mitake
2010-11-10 9:12 ` Ingo Molnar
2010-11-12 15:01 ` Hitoshi Mitake
2010-11-12 15:02 ` [PATCH] perf bench: print both of prefaulted and no prefaulted results Hitoshi Mitake
2010-11-18 7:58 ` Ingo Molnar
2010-11-25 7:04 ` Hitoshi Mitake
2010-11-25 7:04 ` [PATCH v2 1/2] " Hitoshi Mitake
2010-11-26 10:30 ` [tip:perf/core] perf bench: Print both of prefaulted and no prefaulted results by default tip-bot for Hitoshi Mitake
[not found] ` <4D03B1AD.7000606@dcl.info.waseda.ac.jp>
2010-12-12 13:46 ` perf monitoring triggers Was: " Arnaldo Carvalho de Melo
2010-12-13 11:14 ` Peter Zijlstra
2010-12-13 12:38 ` Arnaldo Carvalho de Melo
2010-12-13 12:40 ` Peter Zijlstra
2010-12-13 13:12 ` Arnaldo Carvalho de Melo [this message]
2010-12-13 17:37 ` Hitoshi Mitake
2010-12-14 5:46 ` [RFC PATCH 1/2] perf stat: wait on unix domain socket before calling sys_perf_event_open() Hitoshi Mitake
2010-12-14 5:46 ` [RFC PATCH 2/2] perf bench: more fine grain monitoring for prefault memcpy() Hitoshi Mitake
2010-11-25 7:04 ` [PATCH v2 2/2] perf bench: port arch/x86/lib/memcpy_64.S to perf bench mem memcpy Hitoshi Mitake
2010-11-26 10:31 ` [tip:perf/core] perf bench: Add feature that measures the performance of the arch/x86/lib/memcpy_64.S memcpy routines via 'perf bench mem' tip-bot for Hitoshi Mitake
2010-11-29 13:26 ` Hitoshi Mitake
2011-01-11 16:27 ` [PATCH 2/2] perf bench: add x86-64 specific benchmarks to perf bench mem memcpy Hitoshi Mitake
2010-10-29 19:49 ` [PATCH 1/2] perf bench: port memcpy_64.S to perf bench Peter Zijlstra
2010-10-30 19:21 ` Ingo Molnar
[not found] ` <4D0CE05C.1070600@dcl.info.waseda.ac.jp>
2010-12-20 6:30 ` Miao Xie
2010-12-20 15:34 ` Hitoshi Mitake
[not found] ` <20101029210824.GB13385@ghostprotocols.net>
2010-11-05 17:10 ` Hitoshi Mitake
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=20101213131218.GC5407@ghostprotocols.net \
--to=acme@infradead.org \
--cc=a.p.zijlstra@chello.nl \
--cc=andi@firstfloor.org \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=ling.ma@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miaox@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=mitake@dcl.info.waseda.ac.jp \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=yakui.zhao@intel.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 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.