Re: [PATCH v1 3/3] KVM: arm64: Add histogram stats for handling time of arch specific exit reasons

From: Paolo Bonzini <pbonzini@redhat.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Aaron Lewis <aaronlewis@google.com>, KVM <kvm@vger.kernel.org>,
	Venkatesh Srinivas <venkateshs@google.com>,
	Peter Shier <pshier@google.com>, Ben Gardon <bgardon@google.com>,
	David Matlack <dmatlack@google.com>,
	Will Deacon <will@kernel.org>,
	KVMARM <kvmarm@lists.cs.columbia.edu>,
	Jim Mattson <jmattson@google.com>
Subject: Re: [PATCH v1 3/3] KVM: arm64: Add histogram stats for handling time of arch specific exit reasons
Date: Thu, 23 Sep 2021 11:44:49 +0200	[thread overview]
Message-ID: <2120a93b-2e15-117d-349c-9045cef23439@redhat.com> (raw)
In-Reply-To: <8735pvvip9.wl-maz@kernel.org>

On 23/09/21 09:45, Marc Zyngier wrote:
> On Thu, 23 Sep 2021 07:36:21 +0100,
> Paolo Bonzini <pbonzini@redhat.com> wrote:
>>
>> On 22/09/21 20:53, Marc Zyngier wrote:
>>> I definitely regret adding the current KVM trace points, as they
>>> don't show what I need, and I can't change them as they are ABI.
>>
>> I disagree that they are ABI.  And even if you don't want to change
>> them, you can always add parameters or remove them.
> 
> We'll have to agree to disagree here. Experience has told me that
> anything that gets exposed to userspace has to stay forever. There are
> countless examples of that on the arm64 side (cue the bogomips debate,
> the recent /proc/interrupts repainting).

Files certainly have the problem that there are countless ways to parse 
them, most of them wrong.  This for example was taken into account when 
designing the binary stats format, where it's clear that the only fixed 
format (ABI) is the description of the stats themselves.

However yeah, you're right that what constitutes an API is complicated. 
  Tracepoints and binary stats make it trivial to add stuff (including 
adding more info in the case of a tracepoint), but removing is tricky.

Another important aspect is whether there are at all any tools using the 
tracepoints.  In the case of the block subsystem there's blktrace, but 
KVM doesn't have anything fancy (tracing is really only used by humans 
via trace-cmd, or by kvmstat which doesn't care about which tracepoints 
are there).

> We had that discussion a few KSs ago (triggered by this[1] if I
> remember correctly), and I don't think anything has changed since.
> 
> As for removing them, that would probably be best for some (if not
> most) of them.

I'd say just go ahead.  System calls are removed every now and then if 
they are considered obsolete or a failed experiment.  Tracepoints are in 
the same boat.

Paolo

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm