Messages in this thread | | | Date | Fri, 18 Sep 2020 11:55:56 +0100 | From | Marc Zyngier <> | Subject | Re: [PATCHv3] perf kvm: add kvm-stat for arm64 |
| |
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...
| |