From: Avi Kivity <avi@redhat.com>
To: rostedt@goodmis.org
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Frederic Weisbecker <fweisbec@gmail.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
Johannes Berg <johannes.berg@intel.com>,
Darren Hart <darren@dvhart.com>
Subject: Re: Perf trace event parse errors for KVM events
Date: Tue, 01 Jun 2010 11:39:21 +0300 [thread overview]
Message-ID: <4C04C739.8050607@redhat.com> (raw)
In-Reply-To: <1275233656.15884.4.camel@gandalf.stny.rr.com>
On 05/30/2010 06:34 PM, Steven Rostedt wrote:
>
>> Cool. May make sense to use simpler formatting in the kernel, and use
>> trace-cmd plugins for the complicated cases.
>>
>> It does raise issues with ABIs. Can trace-cmd read plugins from
>> /lib/modules/*? We can then distribute the plugins with the kernel.
>>
>>
> We probably could do that. Perhaps if we can port the python code to
> perf, then it would work for both. Then the plugins could be just python
> scripts, (or binary .so modules) and have a tools/plugins dir?
>
> The python part probably would be easier to port, since the .so modules
> are a bit more specific to trace-cmd.
>
One concern is performance. Traces tend to be long, and running python
code on each line will be slow.
If trace-cmd integrates a pager and a search mechanism that looks at the
binary data instead of the text, we could format only the lines that are
displayed. But that is going to be a lot of work and I don't think it's
worth the effort.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-06-01 8:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-26 12:34 Perf trace event parse errors for KVM events Stefan Hajnoczi
2010-05-28 16:42 ` Stefan Hajnoczi
2010-05-28 21:27 ` Marcelo Tosatti
2010-05-28 21:45 ` Steven Rostedt
2010-05-29 8:21 ` Stefan Hajnoczi
2010-05-29 8:21 ` Stefan Hajnoczi
2010-05-29 11:50 ` Avi Kivity
2010-05-29 13:19 ` Steven Rostedt
2010-05-30 8:10 ` Avi Kivity
2010-05-30 14:03 ` Steven Rostedt
2010-05-30 14:07 ` Avi Kivity
2010-05-30 15:34 ` Steven Rostedt
2010-06-01 8:39 ` Avi Kivity [this message]
2010-06-01 11:59 ` Steven Rostedt
2010-06-01 12:39 ` Avi Kivity
2010-06-03 21:57 ` Steven Rostedt
2010-06-06 8:08 ` Avi Kivity
2010-06-06 15:02 ` Steven Rostedt
2010-06-06 16:21 ` Avi Kivity
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=4C04C739.8050607@redhat.com \
--to=avi@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=darren@dvhart.com \
--cc=fweisbec@gmail.com \
--cc=johannes.berg@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=rostedt@goodmis.org \
--cc=stefanha@gmail.com \
--cc=stefanha@linux.vnet.ibm.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.