Re: [PATCH v7 3/3] KVM: perf: kvm events analysis tool

[David Ahern <dsahern@gmail.com>]

>>   static const char * const kvm_usage[] = {
>> -    "perf kvm [<options>] {top|record|report|diff|buildid-list}",
>> +    "perf kvm [<options>] {top|record|report|diff|buildid-list|stat}",
>>       NULL
>>   };
>>
>
> The usage for the report/record sub commands of stat is never shown. e.g.,
> $ perf kvm stat
> --> shows help for perf-stat
>
> $ perf kvm
> --> shows the above and perf-kvm's usage

[I deleted this thread, so having to reply to one of my responses. 
hopefully noone is unduly harmed by this.]

I've been using this command a bit lately -- especially on nested 
virtualization -- and I think the syntax is quirky - meaning wrong. In 
my case I always follow up a record with a report and end up using a 
shell script wrapper that combines the 2 and running it repeatedly. e.g.,

     $PERF kvm stat record -o $FILE -p $pid -- sleep $time
     [ $? -eq 0 ] && $PERF --no-pager kvm  -i $FILE stat report

As my daughter likes to say - awkward.

That suggests what is really needed is a 'live' mode - a continual 
updating of the output like perf top, not a record and analyze later 
mode. Which does come back to why I responded to this email -- the 
syntax is klunky and awkward.

So, I spent a fair amount of time today implementing a live mode. And 
after a lot of swearing at the tracepoint processing code I finally have 
it working. And the format extends easily (meaning < day and the next 
step) to a perf-based kvm_stat replacement. Example syntax is:

    perf kvm stat [-p <pid>|-a|...]

which defaults to an update delay of 1 second, and vmexit analysis.

The guts of the processing logic come from the existing kvm-events code. 
The changes focus on combining the record and report paths into one. The 
display needs some help (Arnaldo?), but it seems to work well.

I'd like to get opinions on what next? IMO, the record/report path 
should not get a foot hold from a backward compatibility perspective and 
having to maintain those options. I am willing to take the existing 
patches into git to maintain authorship and from there apply patches to 
make the live mode work - which includes a bit of refactoring of perf 
code (like the stats changes).

Before I march down this path, any objections, opinions, etc?

David