On Mon, Mar 01, 2010 at 09:39:04AM +0100, Ingo Molnar wrote:
> > What do you mean by software events?
>
> Things like:
>
> aldebaran:~> perf stat -a sleep 1
>
> Performance counter stats for 'sleep 1':
>
> 15995.719133 task-clock-msecs # 15.981 CPUs
> 5787 context-switches # 0.000 M/sec
> 210 CPU-migrations # 0.000 M/sec
> 193909 page-faults # 0.012 M/sec
> 28704833507 cycles # 1794.532 M/sec (scaled from
> 78.69%)
> 14387445668 instructions # 0.501 IPC (scaled from
> 90.71%)
> 736644616 branches # 46.053 M/sec (scaled from
> 90.52%)
> 695884659 branch-misses # 94.467 % (scaled from
> 90.70%)
> 727070678 cache-references # 45.454 M/sec (scaled from
> 88.11%)
> 1305560420 cache-misses # 81.619 M/sec (scaled from
> 52.00%)
>
> 1.000942399 seconds time elapsed
>
> These lines:
>
> 15995.719133 task-clock-msecs # 15.981 CPUs
> 5787 context-switches # 0.000 M/sec
> 210 CPU-migrations # 0.000 M/sec
> 193909 page-faults # 0.012 M/sec
>
> Are software events of the host - a subset of which could be transparently
> exposed to the guest. Same for tracepoints, probes, etc. Those are not
> exposed
> by the hardware PMU. So by doing a 'soft' PMU (or even better: a paravirt
> channel to perf events) we gain a lot more than just raw PMU functionality.
>
> 'performance events' are about a lot more than just the PMU, it's a coherent
> system health / system events / structured logging framework.
Yeah I know. But these event should be available in the guest already,
no? They don't need any kind of hardware support from the pmu.
A paravirt perf channel from the guest to the host would be definitly a
win. It would be a powerful tool for kvm/linux-guest analysis (e.g.
trace host-kvm and guest-events together on the host)
Joerg
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
