linux-kernel - Re: Perf trace event parse errors for KVM events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 01 Jun 2010 07:59:04 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Avi Kivity <avi@...hat.com>
Cc:	Stefan Hajnoczi <stefanha@...il.com>,
	linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, Frederic Weisbecker <fweisbec@...il.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
	Johannes Berg <johannes.berg@...el.com>,
	Darren Hart <darren@...art.com>
Subject: Re: Perf trace event parse errors for KVM events

On Tue, 2010-06-01 at 11:39 +0300, Avi Kivity wrote:
> 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.
> 

Every event gets its own ID. The plugin registers a callback to that ID.
When the ID is hit, the plugin is executed on that event to display its
binary format.

This is done after the data has been saved in binary format to a file.
It may slow down the executing of reading a data file, but it does not
affect the running of the trace one bit.

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/