Re: 2.6.35-rc1 regression with pvclock and smp guests

[Michael Tokarev <mjt@tls.msk.ru>]

03.10.2010 01:55, Zachary Amsden wrote:
> On 10/01/2010 09:35 PM, Michael Tokarev wrote:
[]
>> [    0.049999] APIC delta adjusted to PM-Timer: 6248670 (6435422)
>> [    0.050298] Booting Node   0, Processors  #1 Ok.
>> [    0.023332] Initializing CPU#1
>>    
> 
> Before this, time is very granular...
>> [    0.063333] kvm-clock: cpu 1, msr 0:1e0a0c1, secondary cpu clock
>> [    0.063333] Brought up 2 CPUs
>> [    0.063333] Total of 2 processors activated (12874.21 BogoMIPS).
>> [    0.076666] x86 PAT enabled: cpu 1, old 0x0, new 0x7010600070106
>> [    0.116666] devtmpfs: initialized
>> [    0.116666] NET: Registered protocol family 16
>> [    0.119999] ACPI: bus type pci registered
> 
> Now it is multiples of 1/300 ....

Note it's second CPU.

>> [    0.249999] Switching to clocksource kvm-clock
>> [    0.259999] pnp: PnP ACPI init
>>    
> 
> Then, of course, it fails.
> 
> What is your host clocksource?  Does your machine have unstable TSC? 
> Here, I have unstable tsc:

Host is using tsc, and this is the only available clocksource now.
It was long time ago when I looked at this last - usually all
standard 3, also hpet and acpi_pm, are available too.  This is
AthlonII CPU, which has synced tsc.  I upgraded the CPU this year
from the previous gen Athlon, -- that one didn't have synced tsc
and kernel were using something else.  So I really don't know why
and when I've only tsc listed on the host (it's 2.6.35.6 x64).

The guest finds usual (in this situation) kvmclock and acpi_pm
(I'm running it with -no-hpet - without it also finds hpet) --
it reports about instability of tsc somewhere in dmesg:

 [1;3/3:   1.004254] Clocksource tsc unstable (delta = 284538419181 ns)

Note this is a regression too, or maybe a bugfix - some time ago,
on another AthlonII machine (also synced tsc), I used to have SMP
guests that used tsc and reported instability of tsc only when
host were swapping (we had a _long_ conversation with Marcelo
Trosati about this somewhere last year, both in public and in
private and on irc, with some bugs fixed after this).  Tha to
say, guests at least had _apparently_ stable tsc before, now
instability is detected right away, with a huge difference too.

I just booted this same guest using kvm-0.12.5 - using that one
guest does not report unstable tsc, yet does not list it in the
available_clocksources.  It also shows time jumps:

...
[0;0/0:    0.000000] Detected 3217.424 MHz processor.
[0;0/0:    0.006666] Calibrating delay loop (skipped) preset value.. 6437.96 BogoMIPS (lpj=10724746)
[0;0/0:    0.006666] pid_max: default: 32768 minimum: 301
[0;0/0:    0.006666] Mount-cache hash table entries: 512
[0;0/0:    0.006765] Initializing cgroup subsys ns
...
[0;0/0:    0.029999] Booting Node   0, Processors  #1 Ok.
[1;0/0:    0.006666] Initializing CPU#1
[1;0/0:    0.006666] kvm-clock: cpu 1, msr 0:1e0a0c1, secondary cpu clock
[0;0/0:    0.058342] Brought up 2 CPUs
...

Thanks!

/mjt