Re: [PATCHv3] perf kvm: add kvm-stat for arm64

[Marc Zyngier]

On 2020-09-18 11:35, Sergey Senozhatsky wrote:
On (20/09/18 09:20), Marc Zyngier wrote:
On 2020-09-18 01:32, Sergey Senozhatsky wrote:
> On (20/09/17 12:53), Marc Zyngier wrote:
> > Feel free to add a *new* tracepoint instead.
>
> Wouldn't we want a whole bunch of new tracepoints in this case?
Yes. I don't have a better solution as long as tracepoints are ABI.

Well, no one does.

Get someone to sign-off on it, and I'll happily change them.

Sorry, I'm not sure I understand this sentence.

What I meant is that the only way to make changes to existing 
tracepoints
would be to get someone like Linus to approve them.

It's all rhetorical anyway, so let's move on.


> (almost all of the existing ones with the extra vcpu_id field).
> Right now we have 3 types of events:
> - events with no vcpu at all        // nil
> - events with vcpu_pc               // "0x%016lx", __entry->vcpu_pc
> - events with (void *)vcpu          // "vcpu: %p", __entry->vcpu
>
> It might be helpful if we could filter out events by vcpu_id.
> But this, basically, doubles the number of events in the ringbuffer.

Only if you enable them both, right?
[..]
How would that double the number of events in the buffer?

Yes. I assume that many scripts do something like "capture kvm:* 
events",
so new and old events are enabled. Unless we want to keep new events in
something like kvm2:* namespace (which is unlikely to happen, I guess).

I really don't mind. I actually like the namespacing, as it gives us
a notion of versioning, something tracepoints lack.. And it gives an
opportunity to argue about the name of the namespace.


And `sudo ./perf stat -e 'kvm:*'` is not unseen. In fact, this is
literally the first thing mentioned at
https://www.linux-kvm.org/page/Perf_events

So if we'll have something like

        trace_kvm_foo(vcpu);
+       trace_kvm_foo2(vcpu->id, vcpu);

for all arm64 kvm events, then we double the number of arm64 kvm:* 
events
in the ringbuffer, don't we? Maybe this is not a gigantic issue, but 
who
knows.

I don't think it's a problem, but I'm more in favour of the namespace
approach.

        M.
--
Jazz is not dead. It just smells funny...