From: tupeng212 <tupeng212@gmail.com>
To: xen-devel <xen-devel@lists.xen.org>
Subject: Big Bug:Time in VM running on xen goes slower
Date: Tue, 7 Aug 2012 23:44:45 +0800 [thread overview]
Message-ID: <201208070018394210381@gmail.com> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 2437 bytes --]
Dear all:
I have found a big bug on xen concerning time virtualization. Please let me show you the whole process:
1 Phenomenon
when I run a JVM based program in IE browser in my Virtual Machine, I have found clearly that time at the right bottom corner in my VM gets more slower and slower.
I studied the bug deeply, and found something below.
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.
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).
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.
there is also a frequently called function going into my eyes: QueryPerformanceCounter.
what my problems are:
1 why the JVM sets the same RTC's rate 976562 down to the coms again and again? what he found is abnormal?
2 even a abnormal user program calls create_periodic_time to set the rate again and again, how do we avoid the influence upon our time in vm? how do we compensate the elapsed time at the switching point? especially when the switch is so frequent.
can some big figures give me some advices on this?
thanks!
tupeng212
[-- Attachment #1.2: Type: text/html, Size: 6758 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next reply other threads:[~2012-08-07 15:44 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 15:44 tupeng212 [this message]
2012-08-08 9:20 ` Big Bug:Time in VM running on xen goes slower Jan Beulich
2012-08-10 15:17 ` Big Bug:Time in VM goes slower; foud Solution but demand Judgement! A Interesting Story! tupeng212
2012-08-13 15:21 ` Jan Beulich
[not found] ` <201208140024353598835@gmail.com>
2012-08-14 6:27 ` Jan Beulich
2012-08-14 6:37 ` Jan Beulich
2012-08-16 13:15 ` Tim Deegan
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=201208070018394210381@gmail.com \
--to=tupeng212@gmail.com \
--cc=xen-devel@lists.xen.org \
/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;
as well as URLs for NNTP newsgroup(s).