Messages in this thread | | | Date | Fri, 18 Sep 2020 19:35:21 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCHv3] perf kvm: add kvm-stat for arm64 |
| |
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.
> > (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).
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.
-ss
| |