On Thu, 2012-05-17 at 09:10 +0400, Dmitry Antipov wrote:
On 05/16/2012 08:58 PM, Steven Rostedt wrote:
On Wed, 2012-05-16 at 11:59 -0300, Arnaldo Carvalho de Melo wrote:
Steve,
Was the kernel trace events infrastructure designed with that in mind? I.e. cross analysis? I must be missing something here, still ENOCOFFEE :-\
Yes, the libparsevents library was design for this from day one. That's why trace-cmd data file can be run on an ARM and read on x86, or PPC, or whatever. I did all my development testing against 32bit, 64bit and big and little endian. This was the case from the beginning.
I didn't face with big/little conversion issues, most probably both x86 and my ARM board are of the same (little) endian :-).
But the original question was about event IDs. For example, /sys/kernel/debug/tracing/events/sched/sched_switch/id is 55 on my ARM board and 279 on my PC host, so 'perf report' displays "unknown:unknown" instead of expected "sched:sched_switch" when attempting to do some cross-analysis. I suppose that original event IDs should be preserved, either within perf.data or by providing the copy of original /sys/kernel/debug/tracing/*, much like it's done with --kallsyms to resolve kernel symbols.
trace-cmd copies the entire /sys/kernel/debug/tracing/events directory into the data file (well it copies only the events you specify). I thought perf did the same. It should be using what's in the perf.dat file and not what's on the host.
Again, perf report is not what uses the events from trace-cmd. It's perf script that does. If perf script works, then perf report needs to be fixed. But after it gets updated to use the latest libparse-events, which I have no idea when that will ever happen.
-- Steve