From: Hollis Blanchard <hollis_blanchard@mentor.com>
To: kvm-ppc@vger.kernel.org
Subject: Re: kvm ppc timing stats
Date: Wed, 08 Dec 2010 00:52:48 +0000 [thread overview]
Message-ID: <4CFED6E0.9040709@mentor.com> (raw)
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA306995614@az33exm25.fsl.freescale.net>
Ah right, makes sense. I guess you'll send a patch soon. :)
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
On 12/07/2010 02:32 PM, Yoder Stuart-B08248 wrote:
> I figure out what is going on here. The timing stats convert
> exit durations into microseconds. The problem is that any
> exits that take less than 1us will wind up having a duration
> of 0. After to changing to count timebase ticks instead, the
> numbers add up.
>
> By the way-- there aren't any instructions accounted for,
> even though they don't cover 100% of the handler-- any
> instructions that run before reading the timestamp will
> get accounted to the guest.
>
> Stuart
>
>> -----Original Message-----
>> From: Hollis Blanchard [mailto:hollis_blanchard@mentor.com]
>> Sent: Thursday, December 02, 2010 12:38 PM
>> To: Yoder Stuart-B08248
>> Cc: kvm-ppc@vger.kernel.org
>> Subject: Re: kvm ppc timing stats
>>
>> 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@mentor.com]
>>>> Sent: Wednesday, December 01, 2010 6:27 PM
>>>> To: Yoder Stuart-B08248
>>>> Cc: kvm-ppc@vger.kernel.org
>>>> 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
>>>>>
>
next prev parent reply other threads:[~2010-12-08 0:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-01 20:20 kvm ppc timing stats Yoder Stuart-B08248
2010-12-01 20:21 ` Alexander Graf
2010-12-02 0:27 ` Hollis Blanchard
2010-12-02 4:18 ` Yoder Stuart-B08248
2010-12-02 18:38 ` Hollis Blanchard
2010-12-07 22:32 ` Yoder Stuart-B08248
2010-12-08 0:52 ` Hollis Blanchard [this message]
2010-12-08 3:13 ` Yoder Stuart-B08248
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CFED6E0.9040709@mentor.com \
--to=hollis_blanchard@mentor.com \
--cc=kvm-ppc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.