On 6/6/13 12:26 PM, Andrew Davidoff wrote:
On Thu, Jun 6, 2013 at 8:01 AM, David Ahern <dsah...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
