Re: [Xen-devel] Big Bug:Time in VM running on xen goes slower

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.08.12 at 17:44, tupeng212 <tupeng212@xxxxxxxxx> wrote:
> 2 Xen
> vmx_vmexit_handler  --> ......... --> handle_rtc_io  --> rtc_ioport_write  
> --> 
> rtc_timer_update --> set RTC's REG_A to a high rate--> 
> create_periodic_time(disable 
> the former timer, and init a new one)
> Win7 is installed in the vm. This calling path is executed so frequent that 
> may come down to set the RTC's REG_A hundreds of times every second but with 
> the same rate(976.562us(1024HZ)), it is so abnormal to me to see such 
> behavior.

_If_ the problem is merely with the high rate of calls to
create_periodic_time(), I think this could be taken care of by
avoiding the call (and perhaps the call to rtc_timer_update() in
the first place) by checking whether anything actually changes
due to the current write. I don't think, however, that this would
help much, as the high rate of port accesses (and hence traps
into the hypervisor) would remain. It might, nevertheless, get
your immediate problem of the time slowing down taken care of
if that is caused inside Xen (but the cause here may as well be in
the Windows kernel).

> 3 OS
> I have tried to find why the win7 setted RTC's regA so frequently. finally 
> got the result, all that comes from a function: NtSetTimerResolution --> 
> 0x70,0x71
> when I attached windbg into the guest OS, I also found the source, they are 
> all called from a upper system call that comes from JVM(Java Virtual 
> Machine).

Getting Windows to be a little smarter and avoid the port I/O when
doing redundant writes would of course be even better, but is
clearly a difficult to achieve goal.

> 4 JVM
> I don't know why JVM calls NtSetTimerResolution to set the same RTC's rate 
> down (976.562us(1024HZ)) so frequently. 
> But found something useful, in the java source code, I found many palaces 
> written with time.scheduleAtFixedRate(), Informations from Internet told me 
> this function scheduleAtFixedRate demands a higher time resolution. so I 
> guess the whole process may be this: 
> java wants a higher time resolution timer, so it changes the RTC's rate from 
> 15.625ms(64HZ) to 976.562us(1024HZ), after that, it reconfirms whether the 
> time is accurate as expected, but it's sorry to get some notice it 's not 
> accurate either. so it sets  the RTC's rate from 15.625ms(64HZ) to 
> 976.562us(1024HZ) again and again..., at last, results in a slow system timer 
> in vm.

Now that's really the fundamental thing to find out - what makes it
think the clock isn't accurate? Is this an artifact of scheduling (as
the scheduler tick certainly is several milliseconds, whereas
"accurate" here appears to require below 1ms granularity), perhaps
as a result of the box being overloaded (i.e. the VM not being able
to get scheduled quickly enough when the timer expires)? For that,
did you try lowering the scheduler time slice and/or its rate limit
(possible via command line option)? Of course doing so may have
other undesirable side effects, but it would be worth a try.

Did you further check whether the adjustments done to the
scheduled time in create_periodic_time() are responsible for this
conclusion of the JVM (could be effectively doubling the first
interval if HVM_PARAM_VPT_ALIGN is set, and with the high rate
of re-sets this could certainly have a more visible effect than
intended)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel