public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "André Przywara" <andre.przywara@arm.com>
To: Christopher Covington <cov@codeaurora.org>, Wei Huang <wei@redhat.com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org,
	kvmarm@lists.cs.columbia.edu, shannon.zhao@linaro.org,
	alistair.francis@xilinx.com, croberts@codeaurora.org,
	alindsay@codeaurora.org, drjones@redhat.com
Subject: Re: [kvm-unit-tests PATCH v13 4/4] arm: pmu: Add CPI checking
Date: Thu, 1 Dec 2016 22:04:18 +0000	[thread overview]
Message-ID: <9e8de357-c1f2-ec44-440d-2b3b7e4ffeb6@arm.com> (raw)
In-Reply-To: <1b3b7bd6-3e53-9d71-d177-933c5a606c16@codeaurora.org>

On 01/12/16 21:18, Christopher Covington wrote:
> On 12/01/2016 03:27 PM, Andre Przywara wrote:

Hi,

....

>>> +		}
>>> +		avg = sum / NR_SAMPLES;
>>> +		printf(" sum=%"PRId64" avg=%"PRId64" avg_ipc=%"PRId64" "
>>> +		       "avg_cpi=%"PRId64"\n", sum, avg, i / avg, avg / i);
>>
>>                 printf(" avg=%4"PRId64": %3"PRId64" %s\n",
>>                        sum / NR_SAMPLES, i > avg ? i / avg : avg / i,
>>                        i > avg ? "ipc" : "cpi");
>>
>> In general I question the usefulness of the cpi/ipc output, it didn't
>> seem meaningful in any way to me, neither in KVM or in TCG.
>> See the last line (68: ...) in the example above, we shouldn't use an
>> average with that deviation for statistical purposes.
>> For KVM I get values ranging from 60 to 4383 cpi, which doesn't convey
>> any real information to me, in fact the actual cycles look like constant
>> to me, probably due to emulation overhead.
>>
>> So what are we supposed to learn from those numbers?
> 
> I think they were mostly useful in debugging the checking of TCG's
> -icount mode, where the numbers are precise.
> 
> I think seeing variable numbers from TCG when -icount is off illustrates
> why -icount is useful. But justifying TCG best practices is a non-goal of
> kvm-unit-tests.
> 
> I'd like to think is possible to see anomalies in the KVM info which are
> due to bugs, but perhaps that's unrealistic or unlikely.
> 
> Feel free to drop the prints, or only print in -icount mode, or only print
> when there's error in -icount mode.

No, it's totally fine to keep them, especially since they only appear
when one runs a test manually.

So thanks for the explanation, those numbers _are_ useful, it was just
me being clueless and/or ignorant ;-)

Cheers,
Andre

P.S. It looks like we should have some documentation, explaining these
numbers, for instance, and the expected results. Along with explanations
what all the other tests do, possibly with pointers where to look for in
case of failures. </enthusiasm>
And no, I am not volunteering, at least not for the PMU ...


      reply	other threads:[~2016-12-01 22:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-01  5:16 [kvm-unit-tests PATCH v13 0/4] ARM PMU tests Wei Huang
2016-12-01  5:16 ` [kvm-unit-tests PATCH v13 1/4] arm: Define macros for accessing system registers Wei Huang
2016-12-01  8:59   ` [Qemu-devel] " Andrew Jones
2016-12-01  9:38     ` Andrew Jones
2016-12-01 11:11     ` Andre Przywara
2016-12-01 13:16       ` Andrew Jones
2016-12-01 15:27     ` Wei Huang
2016-12-01 15:50       ` Andrew Jones
2016-12-01  5:16 ` [kvm-unit-tests PATCH v13 2/4] arm: Add PMU test Wei Huang
2016-12-01  9:03   ` [Qemu-devel] " Andrew Jones
2016-12-01 11:28     ` Andre Przywara
2016-12-01 12:02       ` Peter Maydell
2016-12-01 12:19         ` Andre Przywara
2016-12-01 12:36           ` Peter Maydell
2016-12-01  5:16 ` [kvm-unit-tests PATCH v13 3/4] arm: pmu: Check cycle count increases Wei Huang
2016-12-01  9:18   ` [Qemu-devel] " Andrew Jones
2016-12-01 17:36     ` Wei Huang
2016-12-02  9:58       ` Andrew Jones
2016-12-01 11:27   ` Andre Przywara
2016-12-01 17:39     ` Wei Huang
2016-12-01  5:16 ` [kvm-unit-tests PATCH v13 4/4] arm: pmu: Add CPI checking Wei Huang
2016-12-01  9:26   ` [Qemu-devel] " Andrew Jones
2016-12-01 10:19     ` Andre Przywara
2016-12-01 13:47       ` Andrew Jones
2016-12-01 20:27   ` Andre Przywara
2016-12-01 21:12     ` Wei Huang
2016-12-01 22:11       ` André Przywara
2016-12-01 21:18     ` Christopher Covington
2016-12-01 22:04       ` André Przywara [this message]

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=9e8de357-c1f2-ec44-440d-2b3b7e4ffeb6@arm.com \
    --to=andre.przywara@arm.com \
    --cc=alindsay@codeaurora.org \
    --cc=alistair.francis@xilinx.com \
    --cc=cov@codeaurora.org \
    --cc=croberts@codeaurora.org \
    --cc=drjones@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=qemu-devel@nongnu.org \
    --cc=shannon.zhao@linaro.org \
    --cc=wei@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox