From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Robert Richter <robert.richter@amd.com>,
Andrew Vagin <avagin@openvz.org>,
linux-kernel@vger.kernel.org, paulus@samba.org, mingo@elte.hu,
asharma@fb.com, devel@openvz.org, dsahern@gmail.com,
linux-perf-users@vger.kernel.org
Subject: Re: [PATCH 7/7] event: add tracepoint for accounting block time
Date: Mon, 28 Nov 2011 12:31:40 -0200 [thread overview]
Message-ID: <20111128143140.GA12377@infradead.org> (raw)
In-Reply-To: <4ED39473.9080600@linux.intel.com>
Em Mon, Nov 28, 2011 at 06:02:27AM -0800, Arjan van de Ven escreveu:
> On 11/28/2011 3:42 AM, Peter Zijlstra wrote:
> > On Mon, 2011-11-28 at 12:03 +0300, Andrew Vagin wrote:
> >> This tracepoint shows how long a task is sleeping in uninterruptible state.
> >> E.g.
> >> It may show how long and where a mutex is waited.
> > Fair enough, makes one wonder how much it would take to make
> > account_scheduler_latency() go away..
> I would *love* to switch latencytop to using trace points / perf events.
> But as long as this just means I get yelled at more for using "internal
> ABIs" and the like at various occasions, I'm rather hesitant to turn
> more tools into using perf.
Have you read the the discussion with Robert Richter about that?
https://lkml.org/lkml/2011/11/24/237
perf_evlist is what you call perf_bundle and perf_evsel is what you call
perf_event in powertop.
That part of the API should be ok for wider use and is in fact exported
in the python binding.
I'm rearranging my tmp.perf/trace4 branch into perf/core to ask for
merging, that is a step in the direction of having the 'perf tool' class
added to what will become libperf.so.
I almost embarked into an attempt to make powertop use it, but there are
other stuff to do first, like making the tracepoint based tools already
in perf stop using long if-strcmp(evname, "foo")-call-process_foo_event
(we have IDs, a hash, better use that, etc).
The 'strace' will be Ingo & tglx's 'trace' tool using these changes,
should be done in a way that shows how to use the resulting abstractions
in libperf.so, that together with the other tools already in the kernel
(kmem, lock, etc).
> (and we all know what the next steps to resolve this are, they just have
> not happened yet; not all hope is lost)
Sure its not :-)
- Arnaldo
next prev parent reply other threads:[~2011-11-28 14:31 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-28 9:03 [PATCH 0/7] Profiling sleep times (v3) Andrew Vagin
2011-11-28 9:03 ` [PATCH 1/7] perf: use event_name() to get an event name Andrew Vagin
2011-12-06 14:02 ` Arnaldo Carvalho de Melo
2011-12-08 4:34 ` [tip:perf/urgent] perf header: Use " tip-bot for Andrew Vagin
2011-11-28 9:03 ` [PATCH 2/7] perf: add ability to record event period Andrew Vagin
2011-12-06 14:02 ` Arnaldo Carvalho de Melo
2011-11-28 9:03 ` [PATCH 3/7] perf: add ability to change event according to sample (v2) Andrew Vagin
2011-12-06 14:19 ` Arnaldo Carvalho de Melo
2011-12-06 14:24 ` Arnaldo Carvalho de Melo
2011-12-06 14:57 ` David Ahern
2011-12-06 15:06 ` Arnaldo Carvalho de Melo
2011-11-28 9:03 ` [PATCH 4/7] perf: teach "perf inject" to work with files Andrew Vagin
2011-11-28 9:03 ` [PATCH 5/7] perf: teach perf inject to merge sched_stat_* and sched_switch events Andrew Vagin
2011-11-28 9:03 ` [PATCH 6/7] perf: add scripts for profiling sleep times (v2) Andrew Vagin
2011-11-28 9:03 ` [PATCH 7/7] event: add tracepoint for accounting block time Andrew Vagin
2011-11-28 11:42 ` Peter Zijlstra
2011-11-28 14:02 ` Arjan van de Ven
2011-11-28 14:31 ` Arnaldo Carvalho de Melo [this message]
2011-11-28 14:43 ` Arjan van de Ven
2011-11-28 14:59 ` Arnaldo Carvalho de Melo
2011-12-06 9:48 ` [tip:sched/core] events, sched: Add tracepoint for accounting blocked time tip-bot for Andrew Vagin
2011-12-06 7:15 ` [Devel] [PATCH 0/7] Profiling sleep times (v3) Andrey Vagin
2011-12-06 8:30 ` Ingo Molnar
2011-12-06 13:45 ` Arnaldo Carvalho de Melo
2011-12-07 20:33 ` Arun Sharma
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=20111128143140.GA12377@infradead.org \
--to=acme@infradead.org \
--cc=a.p.zijlstra@chello.nl \
--cc=arjan@linux.intel.com \
--cc=asharma@fb.com \
--cc=avagin@openvz.org \
--cc=devel@openvz.org \
--cc=dsahern@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=robert.richter@amd.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).