Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Fri, 18 Sep 2020 11:55:56 +0100
From:   Marc Zyngier <maz@kernel.org>
To:     Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc:     Leo Yan <leo.yan@linaro.org>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Will Deacon <will@kernel.org>,
        John Garry <john.garry@huawei.com>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        Namhyung Kim <namhyung@kernel.org>,
        Suleiman Souhlal <suleiman@google.com>,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv3] perf kvm: add kvm-stat for arm64
In-Reply-To: <20200918103521.GE3049@jagdpanzerIV.localdomain>
References: <20200917003645.689665-1-sergey.senozhatsky@gmail.com>
 <20200917100950.GC12548@leoy-ThinkPad-X240s>
 <20200917101219.GD12548@leoy-ThinkPad-X240s>
 <652f10660f09bd608b825233713f775a@kernel.org>
 <20200917114231.GE12548@leoy-ThinkPad-X240s>
 <ca309fcda71944455a8c6c1b308886ba@kernel.org>
 <20200918003219.GC3049@jagdpanzerIV.localdomain>
 <f60758eeacb4e94db698d98d6d447939@kernel.org>
 <20200918103521.GE3049@jagdpanzerIV.localdomain>
User-Agent: Roundcube Webmail/1.4.8
Message-ID: <06c3e5d907d1145bf3a7a03de63170ae@kernel.org>
Precedence: bulk

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...