I don't think the numbers added up like that for us either. We treated
them as relative data, not absolute.
I don't remember how early/late the timestamps were recorded, but
obviously they cannot cover 100% of the handler. As the number of exits
increases, those unaccounted-for instructions would add up... but I
wouldn't expect that to cause errors of the magnitude you're seeing.
Perhaps there is a more obvious problem with the way certain exit types
are recorded (or not recorded).
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
On 12/01/2010 08:18 PM, Yoder Stuart-B08248 wrote:
Well, in the example I'm looking at, which runs for 30
seconds, the "sum" column of the stats adds up to
about 10 seconds total. So, there is 20 seconds
unaccounted for.
Interestingly enough, if I let the guest just sit
idle for 30 seconds, the stats do sum up to about
30 seconds.
Will get to the bottom of it, but wanted to make
sure I was not missing something obvious.
Stuart
-----Original Message-----
From: Hollis Blanchard [mailto:hollis_blanchard@xxxxxxxxxx]
Sent: Wednesday, December 01, 2010 6:27 PM
To: Yoder Stuart-B08248
Cc: kvm-ppc@xxxxxxxxxxxxxxx
Subject: Re: kvm ppc timing stats
Yes, your understanding is correct (barring any bugs, of course). Why
do
you think "time is missing"?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
On 12/01/2010 12:02 PM, Yoder Stuart-B08248 wrote:
Hollis,
Am looking at some performance data and want to make sure that
I'm understanding things correctly with your CONFIG_KVM_EXIT_TIMING
stuff. If I reset the timing counters, run a workload
under for a fixed duration (e.g. 30 seconds), and then look
at the exit stats, I should see 30 seconds worth of time accounted
for, correct?
Right now I'm seeing a substantial amount of time "missing" and
want to make sure I'm not missing something.
Stuart
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
