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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
