All of lore.kernel.org
 help / color / mirror / Atom feed
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: Sun, 06 Jun 2010 11:08:31 +0300	[thread overview]
Message-ID: <4C0B577F.9050506@redhat.com> (raw)
In-Reply-To: <1275602225.15884.47.camel@gandalf.stny.rr.com>

On 06/04/2010 12:57 AM, Steven Rostedt wrote:
> On Tue, 2010-06-01 at 15:39 +0300, Avi Kivity wrote:
>    
>> On 06/01/2010 02:59 PM, Steven Rostedt wrote:
>>      
>    
>> I meant that viewing would be slowed down.  It's an important part of
>> using ftrace!
>>
>> How long does the Python formatter take to process 100k or 1M events?
>>
>>      
> I finally got around to testing this.
>
> I ran a trace on lock_acquire, and traced 1,253,296 events.
>
> I then created a python plugin to analyze the trace:
>
> ----
> def lock_acquire(trace_seq, event):
>      t = ''
>      r = ''
>      if int(event['flags'])&  1:
>          t = 'try'
>      if int(event['flags'])&  2:
>          r = 'read'
>      trace_seq.puts('t %x %s%s%s' % (
>              event['lockdep_addr'], t, r,
>              event['name']))
>
> def register(pevent):
>      pevent.register_event_handler("lock", "lock_acquire", lock_acquire)
> ----
>
> Disclaimer, I'm not a python expert, and I'm sure the above python code
> sucks.
>    

I think Python more or less guarantees your code will suck no matter 
what you do.

> [root@ixf9 trace-cmd.git]# time ./trace-cmd report -N>/dev/null 2>&1
>
> real	0m4.653s
> user	0m4.234s
> sys	0m0.419s
>
> * -N keeps trace-cmd from loading any plugins.
>
>
> [root@ixf9 trace-cmd.git]# time PYTHONPATH=`pwd` ./trace-cmd report>/dev/null 2>&1
>
> real	0m53.916s
> user	0m53.047s
> sys	0m0.859s
>
>
> Yes, running a python interpreter is a bit more expensive. It took 4
> seconds to read the million events with plain C, but 53 seconds to read
> it in python.
>
> That said...  This would only affect you if you were writing this to a
> file. I doubt that you would notice this if you were scanning the trace
> with less.
>    

I'm more worried about searching with less.  But a minute for a million 
events isn't that bad.

> Also, I kicked this off in kernelshark, and it made no difference that I
> can see. This is because kernelshark only evaluates the viewable area of
> the screen.
>    

Neat.  Can it also search?  Where can I find it? <googles, finds, gawks>

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2010-06-06  8:08 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
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 [this message]
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=4C0B577F.9050506@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.