All of lore.kernel.org
 help / color / mirror / Atom feed
From: don <haodong@linux.vnet.ibm.com>
To: David Ahern <dsahern@gmail.com>
Cc: avi@redhat.com, acme@infradead.org, mtosatti@redhat.com,
	mingo@elte.hu, xiaoguangrong@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Subject: Re: [PATCH v7 3/3] KVM: perf: kvm events analysis tool
Date: Mon, 03 Sep 2012 16:48:42 +0800	[thread overview]
Message-ID: <50446EEA.5060306@linux.vnet.ibm.com> (raw)
In-Reply-To: <503FB105.9000205@gmail.com>

于 2012年08月31日 02:29, David Ahern 写道:
> In addition to Andrew's comment about making the stats struct and 
> functions generic...
Yes. :-)
>
> On 8/27/12 3:51 AM, Dong Hao wrote:
> ---8<---
>
>> +static void exit_event_decode_key(struct event_key *key, char 
>> decode[20])
>> +{
>> +       const char *exit_reason = get_exit_reason(key->key);
>> +
>> +       snprintf(decode, 20, "%s", exit_reason);
>> +}
>
> Use scnprintf rather than snprintf.
Why? Since we don't care about the return value, what's the difference?
>
> ---8<---
>
>> +static bool kvm_event_expand(struct kvm_event *event, int vcpu_id)
>> +{
>> +    int old_max_vcpu = event->max_vcpu;
>> +
>> +    if (vcpu_id < event->max_vcpu)
>> +        return true;
>> +
>> +    while (event->max_vcpu <= vcpu_id)
>> +        event->max_vcpu += DEFAULT_VCPU_NUM;
>> +
>> +    event->vcpu = realloc(event->vcpu,
>> +                  event->max_vcpu * sizeof(*event->vcpu));
>> +    if (!event->vcpu) {
>
> If realloc fails you leak memory by overwriting the current pointer.
Thanks for pointing it out, we will terminate the running instance in 
our next
version.
>
> ---8<---
>
>> +static double event_stats_stddev(int vcpu_id, struct kvm_event *event)
>> +{
>> +    struct event_stats *stats = &event->total;
>> +    double variance, variance_mean, stddev;
>> +
>> +    if (vcpu_id != -1)
>> +        stats = &event->vcpu[vcpu_id];
>> +
>> +    BUG_ON(!stats->count);
>> +
>> +    variance = stats->M2 / (stats->count - 1);
>> +    variance_mean = variance / stats->count;
>> +    stddev = sqrt(variance_mean);
>> +
>> +    return stddev * 100 / stats->mean;
>> +}
>
> perf should be consistent in the stddev it shows the user. Any reason 
> to dump relative stddev versus stddev used by perf-stat?
Since 'perf stat' uses relative standard deviation rather than stddev, 
'perf kvm stat'
just follows the style of 'perf stat'.

>
> ---8<---
>
>> +/* returns left most element of result, and erase it */
>> +static struct kvm_event *pop_from_result(void)
>> +{
>> +    struct rb_node *node = result.rb_node;
>> +
>> +    if (!node)
>> +        return NULL;
>> +
>> +    while (node->rb_left)
>> +        node = node->rb_left;
>
> Use rb_first().
OK, we will use it in the next version.
>
> ---8<---
>
>> +    /*
>> +     * Append "-a" only if "-p"/"--pid" is not specified since they
>> +     * are mutually exclusive.
>> +     */
>> +    if (!kvm_record_specified_guest(argc, argv))
>> +        rec_argv[i++] = STRDUP_FAIL_EXIT("-a");
>
> Other perf-kvm commands rely on perf-record semantics -- i.e., for 
> user to add the -a or -p option.
You mean, remove '-a' from the default options, then:
if a user wants to record all guest he will use 'perf stat record -a';
and if a user wants to record the specified guest, he should use
'perf stat record -p xxx'?

Well, as the style of other subcommand, e.g., perf lock/perf sched, the
'perf xxx record' record all events on all cpus, no need to use '-a'.

Based on mentioned above, I prefer the original way. ;)
>
> ---8<---
>
>> +static const char * const kvm_events_report_usage[] = {
>> +    "perf kvm stat report [<options>]",
>> +    NULL
>> +};
>> +
>> +static const struct option kvm_events_report_options[] = {
>> +    OPT_STRING(0, "event", &report_event, "report event",
>> +            "event for reporting: vmexit, mmio, ioport"),
>> +    OPT_INTEGER(0, "vcpu", &trace_vcpu,
>> +            "vcpu id to report"),
>> +    OPT_STRING('k', "key", &sort_key, "sort-key",
>> +            "key for sorting: sample(sort by samples number)"
>> +            " time (sort by avg time)"),
>> +    OPT_END()
>> +};
>> +
>> +static int kvm_events_report(int argc, const char **argv)
>> +{
>> +    symbol__init();
>> +
>> +    if (argc) {
>> +        argc = parse_options(argc, argv,
>> +                     kvm_events_report_options,
>> +                     kvm_events_report_usage, 0);
>> +        if (argc)
>> +            usage_with_options(kvm_events_report_usage,
>> +                       kvm_events_report_options);
>> +    }
>> +
>> +    return kvm_events_report_vcpu(trace_vcpu);
>> +}
>> +
>> +static int kvm_cmd_stat(int argc, const char **argv)
>> +{
>> +    if (argc > 1) {
>> +        if (!strncmp(argv[1], "rec", 3))
>> +            return kvm_events_record(argc - 1, argv + 1);
>> +
>> +        if (!strncmp(argv[1], "rep", 3))
>> +            return kvm_events_report(argc - 1 , argv + 1);
>> +    }
>> +
>> +    return cmd_stat(argc, argv, NULL);
>> +}
>> +
>>   static char            name_buffer[256];
>>
>>   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
>
> To get help for the record/report subcommands you have to know that 
> record and report are subcommands.
Okay, we will improve this.
>
> ---8<---
>
>> +static int perf_file_section__read_feature(struct perf_file_section 
>> *section,
>> +                struct perf_header *ph,
>> +                int feat, int fd, void *data)
>> +{
>> +    struct header_read_data *hd = data;
>> +
>> +    if (feat != hd->feat)
>> +        return 0;
>> +
>> +    if (lseek(fd, section->offset, SEEK_SET) == (off_t)-1) {
>> +        pr_debug("Failed to lseek to %" PRIu64 " offset for feature "
>> +                "%d, continuing...\n", section->offset, feat);
>> +    return 0;
>> +    }
>> +
>> +    if (feat >= HEADER_LAST_FEATURE) {
>> +        pr_warning("unknown feature %d\n", feat);
>> +        return 0;
>> +    }
>> +
>> +    hd->result = feat_ops[feat].read(ph, fd);
>
> you should verify the read() function is implemented for the requested 
> feature.
OK, thank you for your comments, we will correct it. :-)

  reply	other threads:[~2012-09-03  8:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-27  9:51 [PATCH v7 0/3] KVM: perf: kvm events analysis tool Dong Hao
2012-08-27  9:51 ` [PATCH v7 1/3] KVM: x86: export svm/vmx exit code and vector code to userspace Dong Hao
2012-09-03 11:13   ` Avi Kivity
2012-09-04  3:53     ` Xiao Guangrong
2012-08-27  9:51 ` [PATCH v7 2/3] KVM: x86: trace mmio begin and complete Dong Hao
2012-09-03 11:07   ` Avi Kivity
2012-09-04  4:06     ` Xiao Guangrong
2012-08-27  9:51 ` [PATCH v7 3/3] KVM: perf: kvm events analysis tool Dong Hao
2012-08-27 15:53   ` Andrew Jones
2012-08-27 19:34     ` David Ahern
2012-08-28  6:35       ` Andrew Jones
2012-08-28 17:19         ` David Ahern
2012-09-02 13:51     ` don
2012-08-30 18:29   ` David Ahern
2012-09-03  8:48     ` don [this message]
2012-09-03 16:04       ` David Ahern
2012-09-13  4:56     ` David Ahern
2012-09-13 13:45       ` Arnaldo Carvalho de Melo
2012-09-13 14:14         ` David Ahern
2012-09-13 14:31           ` Arnaldo Carvalho de Melo
2012-09-14  2:56       ` Xiao Guangrong
2012-09-14 11:51         ` David Ahern
2012-08-27  9:59 ` [PATCH v7 0/3] " Xiao Guangrong
2012-08-27 12:53   ` David Ahern
  -- strict thread matches above, loose matches on Subject: below --
2012-08-24  1:15 Dong Hao
2012-08-24  1:15 ` [PATCH v7 3/3] " Dong Hao
2012-08-24 17:53   ` David Ahern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50446EEA.5060306@linux.vnet.ibm.com \
    --to=haodong@linux.vnet.ibm.com \
    --cc=acme@infradead.org \
    --cc=avi@redhat.com \
    --cc=dsahern@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtosatti@redhat.com \
    --cc=xiaoguangrong@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.