From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Wed, 08 Dec 2010 00:52:48 +0000 Subject: Re: kvm ppc timing stats Message-Id: <4CFED6E0.9040709@mentor.com> List-Id: References: <9696D7A991D0824DBA8DFAC74A9C5FA306995614@az33exm25.fsl.freescale.net> In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA306995614@az33exm25.fsl.freescale.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org 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 >>>>> >