kvm ppc timing stats

kvm ppc timing stats

[Yoder Stuart-B08248]

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

Re: kvm ppc timing stats

[Alexander Graf]

On 01.12.2010, at 21:20, 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.

Christian?


Alex

Re: kvm ppc timing stats

[Hollis Blanchard]

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
>

RE: kvm ppc timing stats

[Yoder Stuart-B08248]

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
> >

Re: kvm ppc timing stats

[Hollis Blanchard]

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
>>>
>

RE: kvm ppc timing stats

[Yoder Stuart-B08248]

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
> >>>
> >

Re: kvm ppc timing stats

[Hollis Blanchard]

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
>>>>>
>

RE: kvm ppc timing stats

[Yoder Stuart-B08248]

> -----Original Message-----
> From: Hollis Blanchard [mailto:hollis_blanchard@mentor.com]
> Sent: Tuesday, December 07, 2010 6:53 PM
> To: Yoder Stuart-B08248
> Cc: kvm-ppc@vger.kernel.org
> Subject: Re: kvm ppc timing stats
> 
> Ah right, makes sense. I guess you'll send a patch soon. :)

Yes.

Stuart