Performance Counter Addresses
Downing, Evan P
edowning3 at gatech.edu
Mon Oct 5 01:40:10 UTC 2015
> We don't use them by default. There is a flag in PerfCounters.h
> determining whether or not to use the extra counters. I think this is
> mostly a legacy of early experiments to move from
> retired-conditional-branches to instructions-retired that are
> essentially abandoned at this stage.
> Can you use rr *outside* of QEMU? And just record all of QEMU?
To clarify a bit more: I am trying to use PANDA and rr together on a project to study the activities of Firefox. During this project I want to use rr as a coarse-grained analysis tool and PANDA as a fine-grained analysis tool. Because I'm using PANDA as a fine-grained analysis tool, I must have it running as rr is running inside the Linux guest. Unfortunately, PANDA is based on QEMU 1.0.1 and is not able to use KVM to record and replay QEMU activity.
How should I combine these tools together to analyze Firefox's activities?
From: Kyle Huey <me at kylehuey.com>
Sent: Sunday, October 4, 2015 8:39 PM
To: Downing, Evan P
Cc: robert at ocallahan.org; rr-dev at mozilla.org
Subject: Re: Performance Counter Addresses
On Sun, Oct 4, 2015 at 5:35 PM, Downing, Evan P <edowning3 at gatech.edu> wrote:
> Responses inline:
>>> rr doesn't depend on the interrupt counter.
> If rr does not depend on the hardware interrupt counter, then why is it
> being used in rr's source code?
We don't use them by default. There is a flag in PerfCounters.h
determining whether or not to use the extra counters. I think this is
mostly a legacy of early experiments to move from
retired-conditional-branches to instructions-retired that are
essentially abandoned at this stage.
>>> It probably wouldn't be very hard to extend QEMU with code to count the
>>> number of retired conditional branches, and an interface to expose that
>>> count to rr (which needs to be able to
>>> read the counter value, reset the counter value to some value, and
>>> trigger an interrupt when the counter value reaches zero). Using the actual
>>> x86 PMU interface might be best since then
>>> you wouldn't have to modify the kernel.
> Very interesting. Thanks!
> I agree that it would be easier to use x86 PMU, but that requires KVM and my
> project is not compatible with KVM. Am I correct?
>>> However, I still don't know what your ultimate goal is, but you might be
>>> better off forward-porting your code to a newer version of QEMU and using
>>> something like PANDA
>>> (https://github.com/moyix/panda) which supports record and replay built
>>> into QEMU.
> Thanks for the advice!
> Unfortunately, I need to use rr though for this specific project.
Can you use rr *outside* of QEMU? And just record all of QEMU?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rr-dev