Re: RFC: paravirtualizing perf_clock

From: David Ahern
Date: Wed Oct 30 2013 - 10:31:39 EST

On 10/30/13 8:20 AM, Gleb Natapov wrote:
So can you explain a little bit more about how this will work? You run
perf on a host and get both host and guest events? How do you pass
events from guest to host in this case?

The intent is to allow data capture to occur in both contexts (host and guest) completely independently (e.g., record events in the guest to a file and in the host to a separate file). The files are then made available to a single post processing command (e.g., copy off box to an analysis server or copy guest file to host or vice versa).

From there perf needs some tweaks to read 2 different data files and sort. From an address to symbol perspective, perf already has the notion of independent machines -- work that was done for perf-kvm. There has already been a lot of discussion on writing perf events to mmap-specific files which are then merged at analysis time (versus today where all mmap's are scanned and dumped to the same file). This use case is not much of an extension beyond those two concepts.

Right now, as a proof of concept, I am dumping events in the guest to a file (perf-script) and in the host to a file, merging the two files together and then time sorting. For example running, 'ls' in the guest causes disk I/O which causes a VMEXIT, .... you can see this action end to end.

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

MSR is x86 thing.

Sure the implementation of pv_perf_clock for x86 is an MSR read (open to suggestions on other options). ARM would have some other means of a fast access to host, no?

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