adding trace-cmd's plugins to perf

DISCUSSION David Ahern 4 participants 8 messages Apr 10, 2011 – Apr 12, 2011

lore

Share & tools

lore

David Ahern

author

2011-04-10 03:50 UTC #0 lore raw

Right now perf script cannot process kvm tracepoints:

perf record -e kvm:* -p 6446 -- sleep 5

perf script
Warning: Error: expected type 4 but read 7
Warning: Error: expected type 5 but read 0
Warning: failed to read event print fmt for kvm_apic
Warning: Error: expected type 4 but read 7
Warning: Error: expected type 5 but read 0
Warning: failed to read event print fmt for kvm_inj_exception
Fatal: bad op token {

trace-cmd can parse the events through the kvm plugin.

As I understand it trace-cmd and perf have a lot of similar code, so I would expect to be able to add the plugin capability to perf somewhat easily. However, that does not seem to be the right thing to do (copying yet more code between the two).

Before I invest a lot of time on this path I figured I should ask what the intentions (roadmap seems to be too formal a word ;-)) are about merging common code between the two commands. Also, trace-cmd and perf are in separate repositories so a shared lib is going to inconvenience one of the two.

Thanks,
David

Frederic Weisbecker

2011-04-12 16:22 UTC #1 lore raw

Quoted 15 lines · David Ahern

Right now perf script cannot process kvm tracepoints:
perf record -e kvm:* -p 6446 -- sleep 5
perf script
Warning: Error: expected type 4 but read 7
Warning: Error: expected type 5 but read 0
Warning: failed to read event print fmt for kvm_apic
Warning: Error: expected type 4 but read 7
Warning: Error: expected type 5 but read 0
Warning: failed to read event print fmt for kvm_inj_exception
Fatal: bad op token {
trace-cmd can parse the events through the kvm plugin.

Quoted 7 lines

As I understand it trace-cmd and perf have a lot of similar code, so I would expect to be able to add the plugin capability to perf somewhat easily. However, that does not seem to be the right thing to do (copying yet more code between the two).
Before I invest a lot of time on this path I figured I should ask what the intentions (roadmap seems to be too formal a word ;-))

Hehe :)

Quoted 3 lines

are about merging common code between the two commands. Also, trace-cmd and perf are in separate repositories so a shared lib is going to inconvenience one of the two.

So, we copied the tools/perf/util/trace-event-* files from trace-cmd to perf a while go. Then both files took their own path, both pulling fixes/enhancement from each others (probably more in the trace-cmd -> perf direction).

And perf is indeed a bit backward wrt parsing, because it lacks those plugins for example. So now it would be nice to unify that in a common lib so that it works well in both.

Steve proposed a shared tools/trace.so, that perf and trace-cmd could plug into, I really would like to see that happening too.

I think Ingo had some reserves about this, due to potential versioning and compatibility that such a dynamic lib would involve.

However, this seems to me a very important and necessary step to unify our tools.

Arnaldo Carvalho de Melo

2011-04-12 18:35 UTC #2 lore raw

Em Tue, Apr 12, 2011 at 06:22:47PM +0200, Frederic Weisbecker escreveu:

Quoted 20 lines · David Ahern

Quoted 10 lines
Right now perf script cannot process kvm tracepoints:
perf record -e kvm:* -p 6446 -- sleep 5
perf script
Warning: Error: expected type 4 but read 7
are about merging common code between the two commands. Also, trace-cmd and perf are in separate repositories so a shared lib is going to inconvenience one of the two.
So, we copied the tools/perf/util/trace-event-* files from trace-cmd to perf a while go. Then both files took their own path, both pulling fixes/enhancement from each others (probably more in the trace-cmd -> perf direction).
And perf is indeed a bit backward wrt parsing, because it lacks those plugins for example. So now it would be nice to unify that in a common lib so that it works well in both.

Quoted 5 lines

Steve proposed a shared tools/trace.so, that perf and trace-cmd could plug into, I really would like to see that happening too.
I think Ingo had some reserves about this, due to potential versioning and compatibility that such a dynamic lib would involve.

So we don't commit to an ABI for a while, just linking with it, changing users when changing the ABI.

I encourage David to go and add the bits of trace-cmd he needs for support the plugins he wants used in perf on tools/lib/ and make perf use it.

That way we again reduce the differences between the codebases, or at least reduce the feature gap.

- Arnaldo

Borislav Petkov

2011-04-12 18:51 UTC #3 lore raw

Quoted 30 lines · Arnaldo Carvalho de Melo

Em Tue, Apr 12, 2011 at 06:22:47PM +0200, Frederic Weisbecker escreveu:
Quoted 20 lines · David Ahern
Quoted 10 lines
Right now perf script cannot process kvm tracepoints:
perf record -e kvm:* -p 6446 -- sleep 5
perf script
Warning: Error: expected type 4 but read 7
are about merging common code between the two commands. Also, trace-cmd and perf are in separate repositories so a shared lib is going to inconvenience one of the two.
So, we copied the tools/perf/util/trace-event-* files from trace-cmd to perf a while go. Then both files took their own path, both pulling fixes/enhancement from each others (probably more in the trace-cmd -> perf direction).
And perf is indeed a bit backward wrt parsing, because it lacks those plugins for example. So now it would be nice to unify that in a common lib so that it works well in both.
Quoted 5 lines
Steve proposed a shared tools/trace.so, that perf and trace-cmd could plug into, I really would like to see that happening too.
I think Ingo had some reserves about this, due to potential versioning and compatibility that such a dynamic lib would involve.
So we don't commit to an ABI for a while, just linking with it, changing users when changing the ABI.

Quoted 6 lines

I encourage David to go and add the bits of trace-cmd he needs for support the plugins he wants used in perf on tools/lib/ and make perf use it.
That way we again reduce the differences between the codebases, or at least reduce the feature gap.

Also, just FYI, I have this RAS daemon patchset which splits perf functionality into different sub-libs, which are more or less topic based:

tools/lib/trace/ - all the trace-event* stuff from Steven
tools/lib/lk/ - generic enough stuff (git headers, etc) which several tools could use
tools/lib/perf/ - functionality related to perf events

Here's the last submission http://marc.info/?l=linux-edac&m=129562244211501&w=2
and I'm currently finishing a new rebase against tip/perf/core.

If you're fine with that split I'd suggest I load off my stuff first so that David can continue from there and I can finally stop rebasing like crazy each time perf moves forward.

Opinions? Suggestions?

Thanks.

Signature · 2 lines

Regards/Gruss,
    Boris.

Arnaldo Carvalho de Melo

2011-04-12 18:57 UTC #4 lore raw

Em Tue, Apr 12, 2011 at 08:51:04PM +0200, Borislav Petkov escreveu:

Quoted 45 lines · Arnaldo Carvalho de Melo

Quoted 30 lines
Em Tue, Apr 12, 2011 at 06:22:47PM +0200, Frederic Weisbecker escreveu:
Quoted 20 lines · David Ahern
Quoted 10 lines
Right now perf script cannot process kvm tracepoints:
perf record -e kvm:* -p 6446 -- sleep 5
perf script
Warning: Error: expected type 4 but read 7
are about merging common code between the two commands. Also, trace-cmd and perf are in separate repositories so a shared lib is going to inconvenience one of the two.
So, we copied the tools/perf/util/trace-event-* files from trace-cmd to perf a while go. Then both files took their own path, both pulling fixes/enhancement from each others (probably more in the trace-cmd -> perf direction).
And perf is indeed a bit backward wrt parsing, because it lacks those plugins for example. So now it would be nice to unify that in a common lib so that it works well in both.
Quoted 5 lines
Steve proposed a shared tools/trace.so, that perf and trace-cmd could plug into, I really would like to see that happening too.
I think Ingo had some reserves about this, due to potential versioning and compatibility that such a dynamic lib would involve.
So we don't commit to an ABI for a while, just linking with it, changing users when changing the ABI.
Quoted 6 lines
I encourage David to go and add the bits of trace-cmd he needs for support the plugins he wants used in perf on tools/lib/ and make perf use it.
That way we again reduce the differences between the codebases, or at least reduce the feature gap.
Also, just FYI, I have this RAS daemon patchset which splits perf functionality into different sub-libs, which are more or less topic based:
tools/lib/trace/ - all the trace-event* stuff from Steven
tools/lib/lk/ - generic enough stuff (git headers, etc) which several tools could use
tools/lib/perf/ - functionality related to perf events

Quoted 8 lines

Here's the last submission http://marc.info/?l=linux-edac&m=129562244211501&w=2
and I'm currently finishing a new rebase against tip/perf/core.
If you're fine with that split I'd suggest I load off my stuff first so that David can continue from there and I can finally stop rebasing like crazy each time perf moves forward.
Opinions? Suggestions?

Yeah, David, can you try Borislav's patchset and tell us what you think wrt servicing your needs?

- Arnaldo

Borislav Petkov

2011-04-12 19:01 UTC #5 lore raw

Quoted 49 lines · Arnaldo Carvalho de Melo

Em Tue, Apr 12, 2011 at 08:51:04PM +0200, Borislav Petkov escreveu:
Quoted 48 lines · Arnaldo Carvalho de Melo
Quoted 30 lines
Em Tue, Apr 12, 2011 at 06:22:47PM +0200, Frederic Weisbecker escreveu:
Quoted 20 lines · David Ahern
Quoted 10 lines
Right now perf script cannot process kvm tracepoints:
perf record -e kvm:* -p 6446 -- sleep 5
perf script
Warning: Error: expected type 4 but read 7
are about merging common code between the two commands. Also, trace-cmd and perf are in separate repositories so a shared lib is going to inconvenience one of the two.
So, we copied the tools/perf/util/trace-event-* files from trace-cmd to perf a while go. Then both files took their own path, both pulling fixes/enhancement from each others (probably more in the trace-cmd -> perf direction).
And perf is indeed a bit backward wrt parsing, because it lacks those plugins for example. So now it would be nice to unify that in a common lib so that it works well in both.
Quoted 5 lines
Steve proposed a shared tools/trace.so, that perf and trace-cmd could plug into, I really would like to see that happening too.
I think Ingo had some reserves about this, due to potential versioning and compatibility that such a dynamic lib would involve.
So we don't commit to an ABI for a while, just linking with it, changing users when changing the ABI.
Quoted 6 lines
I encourage David to go and add the bits of trace-cmd he needs for support the plugins he wants used in perf on tools/lib/ and make perf use it.
That way we again reduce the differences between the codebases, or at least reduce the feature gap.
Also, just FYI, I have this RAS daemon patchset which splits perf functionality into different sub-libs, which are more or less topic based:
tools/lib/trace/ - all the trace-event* stuff from Steven
tools/lib/lk/ - generic enough stuff (git headers, etc) which several tools could use
tools/lib/perf/ - functionality related to perf events
Here's the last submission http://marc.info/?l=linux-edac&m=129562244211501&w=2
and I'm currently finishing a new rebase against tip/perf/core.

Quoted 8 lines

Quoted 5 lines
If you're fine with that split I'd suggest I load off my stuff first so that David can continue from there and I can finally stop rebasing like crazy each time perf moves forward.
Opinions? Suggestions?
Yeah, David, can you try Borislav's patchset and tell us what you think wrt servicing your needs?

Yeah, but first let me post the latest version - I'll try to do so in the next couple of days.

Thanks.

Signature · 2 lines

Regards/Gruss,
    Boris.

David Ahern

author

2011-04-12 19:39 UTC #6 lore raw

Quoted 5 lines · Borislav Petkov

Quoted 5 lines
Quoted 5 lines
Also, just FYI, I have this RAS daemon patchset which splits perf functionality into different sub-libs, which are more or less topic based:
tools/lib/trace/ - all the trace-event* stuff from Steven
tools/lib/lk/ - generic enough stuff (git headers, etc) which several tools could use

Is this going to contain the option parsing as well? e.g., something tools/kvm is picking up from perf.

Quoted 11 lines

Quoted 11 lines
Quoted 10 lines
tools/lib/perf/ - functionality related to perf events
Here's the last submission http://marc.info/?l=linux-edac&m=129562244211501&w=2
and I'm currently finishing a new rebase against tip/perf/core.
If you're fine with that split I'd suggest I load off my stuff first so that David can continue from there and I can finally stop rebasing like crazy each time perf moves forward.
Opinions? Suggestions?

Quoted 8 lines

Quoted 2 lines
Yeah, David, can you try Borislav's patchset and tell us what you think wrt servicing your needs?
Yeah, but first let me post the latest version - I'll try to do so in the next couple of days.
Thanks.

Sure. This is a background task, and I still need to spend time on trace-cmd to understand it. ie. it's not something I expect to do within the next week -- more like within the next month if I get the time.

David

Borislav Petkov

2011-04-12 20:02 UTC #7 lore raw

Quoted 11 lines · David Ahern

Quoted 5 lines · Borislav Petkov
Quoted 5 lines
Quoted 5 lines
Also, just FYI, I have this RAS daemon patchset which splits perf functionality into different sub-libs, which are more or less topic based:
tools/lib/trace/ - all the trace-event* stuff from Steven
tools/lib/lk/ - generic enough stuff (git headers, etc) which several tools could use
Is this going to contain the option parsing as well? e.g., something tools/kvm is picking up from perf.

Nope, not yet. Acme suggested I export only the stuff I need. But you can definitely add them there since I have the Makefiles adjusted and you'd have to move the .[ch] files and adjust the includes.

Here's what's there so far:

lib/lk/

|-- cpumap.c
|-- cpumap.h
|-- ctype.c
|-- debugfs.c
|-- debugfs.h
|-- Makefile
|-- thread_map.c
|-- thread_map.h
|-- types.h
|-- usage.c
|-- util.c
|-- util.h
|-- xyarray.c

`-- xyarray.h

Quoted 17 lines

Quoted 17 lines
Quoted 5 lines
Quoted 5 lines
tools/lib/perf/ - functionality related to perf events
Here's the last submission http://marc.info/?l=linux-edac&m=129562244211501&w=2
and I'm currently finishing a new rebase against tip/perf/core.
Quoted 8 lines
Quoted 5 lines
If you're fine with that split I'd suggest I load off my stuff first so that David can continue from there and I can finally stop rebasing like crazy each time perf moves forward.
Opinions? Suggestions?
Yeah, David, can you try Borislav's patchset and tell us what you think wrt servicing your needs?
Yeah, but first let me post the latest version - I'll try to do so in the next couple of days.

Quoted 6 lines

Quoted 2 lines
Thanks.
Sure. This is a background task, and I still need to spend time on trace-cmd to understand it. ie. it's not something I expect to do within the next week -- more like within the next month if I get the time.

Ok, I'll let you know when I have it done.

Signature · 2 lines

Regards/Gruss,
    Boris.