[lkml]   [2013]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: paravirtualizing perf_clock
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?


 \ /
  Last update: 2013-10-30 16:01    [W:0.068 / U:40.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site