Re: Getting started with perf; a couple of questions

[David Ahern <dsahern@gmail.com>]

On 6/6/13 12:26 PM, Andrew Davidoff wrote:
> On Thu, Jun 6, 2013 at 8:01 AM, David Ahern <dsahern@gmail.com> wrote:
>>
>> It's a VM and not running on KVM so there is no PMU which means the -e
>> cycles is most likely falling back to -e cpu-clock. You should see this in a
>> message with the -v flag on record. perf-script should dump out the events
>> and show cpu-clock versus cycles.
>>
>> Based on that I suggest trying -e cpu-clock on your original host. If that
>> works then something is messed up with the pmu config on the host.
>
> Thanks. It wasn't clear to me if a VM had the same access to the PMU
> that a non-virtualized host would. But I guess that might explain why
> a bunch of events I'd expect samples for didn't have any (ex:
> iTLB-load-misses), even on the VM that did record some samples?
>

The hypervisor needs to expose a PMU to the guest. AFAIK KVM is the only 
one that does that. Without the PMU you do not get H/W based events.

> I re-ran the record on the VM with -v and did see the message about
> falling back to cpu-clock-ticks, but only after I added the cycles
> even to my events list. Which actually leads into a question regarding
> event sampling.

So perf record -v does not show the fallback? The default event has been 
'cycles' from the beginning I believe. Only if cycles is not supported 
does it fallback to cpu-clock. You should not have to add '-e cycles'. 
Well, at least that is the way it is for the code in Linus' tree.

>
> The documentation I have found mentions a "default sampling event"
> (cycles) but doesn't explain the concept of a sampling event in
> detail. Does each event listed with -e have its own sample period/rate
> that can be adjusted? Or do -c or -F apply to all events sampled? Even
> I don't sample cycles, is the default sampling rate still 1000Hz for
> all events sampled in the absence of -c or -F?

Unless it crept it with some changes Jiri made (I have not been using 
the fancy -e declarations) I believe there is a single -c/-F argument 
and it applies to all events. ie., all events have the same sampling 
interval.

The default is 1000 Hz (equivalent to -F 1000). -c specifies the period 
-- which is the similar to specifying -F.

     OPT_U64('c', "count", &record.opts.user_interval, "event period to 
sample"),
...
     OPT_UINTEGER('F', "freq", &record.opts.user_freq, "profile at this 
frequency"),


And then configuring the attributes for the event only 1 of the 2 is 
used with frequency taking precedent:

    if (!attr->sample_period || (opts->user_freq != UINT_MAX &&
                      opts->user_interval != ULLONG_MAX)) {
         if (opts->freq) {
             perf_evsel__set_sample_bit(evsel, PERIOD);
             attr->freq      = 1;
             attr->sample_freq   = opts->freq;
         } else {
             attr->sample_period = opts->default_interval;
         }
     }

>
> Regarding using -e cpu-clock on the original host, that doesn't appear
> to have changed the perf record behavior. Neither does using -e
> cycles. And even with -v on record, I didn't see any additional
> messaging (like fall back to cpu-clock). But I do still get sample
> data if I run with -a. *shrug*.

What command lines are you running? I seem to recall this is a 2.6.32 
kernel and basic perf record commands should work fine -- perf record -a 
or perf record -p <pid>. Perhaps something snuck in recently that broke 
compat with 2.6.32. You can determine that by running the perf command 
that comes with that version of Ubuntu and then newer ones -- 3.0, 3.4, 
3.8 would be a good distribution of versions to start with if you want 
to get to the bottom of it.

David