From: Chris J Arges <chris.j.arges@canonical.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: kvm-unit-test failures
Date: Wed, 03 Sep 2014 11:23:27 -0500 [thread overview]
Message-ID: <5407407F.3060500@canonical.com> (raw)
In-Reply-To: <54072CBF.7080108@redhat.com>
On 09/03/2014 09:59 AM, Paolo Bonzini wrote:
> Il 02/09/2014 21:57, Chris J Arges ha scritto:
>> Seconds get from host: 1409687073
>> Seconds get from kvmclock: 1409333034
>> Offset: -354039
>> offset too large!
>> Check the stability of raw cycle ...
>> Worst warp -354462672821748
>> Total vcpus: 2
>> Test loops: 10000000
>> Total warps: 1
>> Total stalls: 0
>> Worst warp: -354462672821748
>> Raw cycle is not stable
>> Monotonic cycle test:
>> Worst warp -354455286691490
>
> Looks like one CPU is not being initialized correctly:
>
> - The "next" correction in the trace is 18445647546048704244,
> and (next-2^64) / -354039 is about 3.1*10^9. This is a pretty
> plausible value of the TSC frequency. As a comparison, on my machine
> I have next=18446366988261784997 and an uptime of 29:12 hours, and
> the two match nicely with the CPU clock:
>
> -(18446366988261784997-2^64) / (29.2 * 3600 * 10^9) = 3.587
>
> $ grep -m1 model.name /proc/cpuinfo
> model name : Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz
>
> - The offset in seconds * 10^9 is pretty close to the warp in nanoseconds.
>
> Can you: 1) try this patch 2) gather a new trace 3) include uptime and
> cpuinfo in your report? All this without clocksource=hpet of course.
>
> Thanks,
>
> Paolo
>
> diff --git a/x86/kvmclock_test.c b/x86/kvmclock_test.c
> index 52a43fb..f68881c 100644
> --- a/x86/kvmclock_test.c
> +++ b/x86/kvmclock_test.c
> @@ -7,6 +7,9 @@
> #define DEFAULT_TEST_LOOPS 100000000L
> #define DEFAULT_THRESHOLD 5L
>
> +long threshold = DEFAULT_THRESHOLD;
> +int nerr = 0;
> +
> struct test_info {
> struct spinlock lock;
> long loops; /* test loops */
> @@ -20,8 +23,9 @@ struct test_info {
>
> struct test_info ti[4];
>
> -static int wallclock_test(long sec, long threshold)
> +static void wallclock_test(void *p_sec)
> {
> + long sec = *(long *)p_sec;
> long ksec, offset;
> struct timespec ts;
>
> @@ -36,10 +40,8 @@ static int wallclock_test(long sec, long threshold)
>
> if (offset > threshold || offset < -threshold) {
> printf("offset too large!\n");
> - return 1;
> + nerr++;
> }
> -
> - return 0;
> }
>
> static void kvm_clock_test(void *data)
> @@ -116,10 +118,9 @@ static int cycle_test(int ncpus, long loops, int check, struct test_info *ti)
> int main(int ac, char **av)
> {
> int ncpus;
> - int nerr = 0, i;
> + int i;
> long loops = DEFAULT_TEST_LOOPS;
> long sec = 0;
> - long threshold = DEFAULT_THRESHOLD;
>
> if (ac > 1)
> loops = atol(av[1]);
> @@ -137,7 +138,8 @@ int main(int ac, char **av)
> on_cpu(i, kvm_clock_init, (void *)0);
>
> if (ac > 2)
> - nerr += wallclock_test(sec, threshold);
> + for (i = 0; i < ncpus; ++i)
> + on_cpu(i, wallclock_test, &sec);
>
> printf("Check the stability of raw cycle ...\n");
> pvclock_set_flags(PVCLOCK_TSC_STABLE_BIT
>
Here are the results of the trace as you requested:
http://people.canonical.com/~arges/kvm/trace-2.dat.xz
$ uptime
16:18:31 up 53 min, 1 user, load average: 1.16, 0.39, 0.17
$ grep -m1 model.name /proc/cpuinfo
model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
Here is the output of the command:
qemu-system-x86_64 -enable-kvm -device pc-testdev -device
isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio
-device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append
10000000 1409761075
enabling apic
enabling apic
kvm-clock: cpu 0, msr 0x:44e520
kvm-clock: cpu 0, msr 0x:44e520
Wallclock test, threshold 5
Seconds get from host: 1409761075
Seconds get from kvmclock: 1409757927
Offset: -3148
offset too large!
Wallclock test, threshold 5
Seconds get from host: 1409761075
Seconds get from kvmclock: 1409757927
Offset: -3148
offset too large!
Check the stability of raw cycle ...
Worst warp -3147762665310
Total vcpus: 2
Test loops: 10000000
Total warps: 1
Total stalls: 0
Worst warp: -3147762665310
Raw cycle is not stable
Monotonic cycle test:
Worst warp -3142929472775
Total vcpus: 2
Test loops: 10000000
Total warps: 1
Total stalls: 0
Worst warp: -3142929472775
Measure the performance of raw cycle ...
Total vcpus: 2
Test loops: 10000000
TSC cycles: 1242044050
Measure the performance of adjusted cycle ...
Total vcpus: 2
Test loops: 10000000
TSC cycles: 1242665486
Return value from qemu: 3
--chris
next prev parent reply other threads:[~2014-09-03 16:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-26 18:29 [PATCH 0/2] kvm-unit-tests: add check parameter to run_tests configuration Chris J Arges
2014-08-26 18:29 ` [PATCH 1/2] " Chris J Arges
2014-08-27 13:29 ` Paolo Bonzini
2014-08-27 14:42 ` [PATCH 1/2 v2] " Chris J Arges
2014-08-27 14:45 ` [PATCH 1/2 v3] " Chris J Arges
2014-08-27 14:52 ` Paolo Bonzini
2014-08-27 21:24 ` kvm-unit-test failures (was: [PATCH 1/2 v3] add check parameter to run_tests configuration) Chris J Arges
2014-08-27 22:05 ` Paolo Bonzini
2014-08-29 17:36 ` kvm-unit-test failures Chris J Arges
2014-08-29 21:05 ` Chris J Arges
2014-08-31 16:05 ` Paolo Bonzini
2014-09-02 19:57 ` Chris J Arges
2014-09-03 14:47 ` Paolo Bonzini
2014-09-03 15:21 ` Chris J Arges
2014-09-03 14:59 ` Paolo Bonzini
2014-09-03 16:23 ` Chris J Arges [this message]
2014-09-03 17:52 ` Paolo Bonzini
2014-09-03 18:25 ` Chris J Arges
[not found] ` <54083688.6000201@redhat.com>
2014-09-04 11:33 ` Paolo Bonzini
2014-09-04 12:24 ` Wanpeng Li
2014-09-04 13:11 ` Paolo Bonzini
2014-08-29 21:08 ` Paolo Bonzini
2014-08-29 21:18 ` Chris J Arges
2014-08-26 18:29 ` [PATCH 2/2] x86/unittests.cfg: the pmu testcase requires that nmi_watchdog is disabled Chris J Arges
2014-08-27 13:29 ` Paolo Bonzini
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=5407407F.3060500@canonical.com \
--to=chris.j.arges@canonical.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@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 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.