Re: RFC: paravirtualizing perf_clock

From: David Ahern
Date: Mon Oct 28 2013 - 22:58:36 EST

On 10/28/13 7:15 AM, Peter Zijlstra wrote:
Any suggestions on how to do this and without impacting performance. I
noticed the MSR path seems to take about twice as long as the current
implementation (which I believe results in rdtsc in the VM for x86 with
stable TSC).

So assuming all the TSCs are in fact stable; you could implement this by
syncing up the guest TSC to the host TSC on guest boot. I don't think
anything _should_ rely on the absolute TSC value.

Of course you then also need to make sure the host and guest tsc
multipliers (cyc2ns) are identical, you can play games with
cyc2ns_offset if you're brave.

This and the method Gleb mentioned both are going to be complex and fragile -- based assumptions on how the perf_clock timestamps are generated. For example, 489223e assumes you have the tracepoint enabled at VM start with some means of capturing the data (e.g., a perf-session active). In both cases the end result requires piecing together and re-generating the VM's timestamp on the events. For perf this means either modifying the tool to take parameters and an algorithm on how to modify the timestamp or a homegrown tool to regenerate the file with updated timestamps.

To back out a bit, my end goal is to be able to create and merge perf-events from any context on a KVM-based host -- guest userspace, guest kernel space, host userspace and host kernel space (userspace events with a perf-clock timestamp is another topic ;-)). Having the events generated with the proper timestamp is the simpler approach than trying to collect various tidbits of data, massage timestamps (and hoping the clock source hasn't changed) and then merge events.

And then for the cherry on top a design that works across architectures (e.g., x86 now, but arm later).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at