Hide Forgot
Description of problem: Should have a vread implementation using kvmclock when it is stable and available. This needs to be implemented and tested upstream. May also require libc changes to be effective. This should be doable on machines with stable TSC now that we have fancy TSC offset-matching upstream (and KVM clock offset-matching soon to be there).
Not proposed for 6.1, this would be for 6.2. Too late to add untested kernel changes this late in the game.
TSC scaling has derailed this bug quite a bit by making it substantially more complex to implement; still it may be possible for 6.2 if I can clear the other, more serious issues first. Requesting pm ack
This turned out to be a lot more work than anticipated... it's going to require RDTSCP to do this properly
For the record, comparison of native vs guest gettimeofday performance: model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz native, gettimeofday (vsyscall): 45ns guest, kvmclock (syscall): 198ns
> Andrew Theurer wrote: >> Wondering if a user-space gettimofday() for kvm-clock has been >> considered before. I am seeing a pretty large difference in >> performance between tsc and kvm-clock. I have to assume at least >> some of this is due to the mode switch for kvm-clock. Here are the >> results: >> >> (this is a 16 vCPU VM on a 16 thread 2S Nehalem-EP host, looped >> gettimeofday() calls on all vCPUs) >> >> tsc: .0645 usec per call >> kvm-clock: .4222 usec per call (6.54x) >> >> >> -Andrew Theurer > > https://bugzilla.redhat.com/show_bug.cgi?id=679207 > > "model name : Intel(R) Xeon(R) CPU E5540 @ 2.53GHz > > native, gettimeofday (vsyscall): 45ns > guest, kvmclock (syscall): 198ns" > > But this was before > > commit 489fb490dbf8dab0249ad82b56688ae3842a79e8 > Author: Glauber Costa<glommer> > Date: Tue May 11 12:17:40 2010 -0400 > > x86, paravirt: Add a global synchronization point for pvclock > > (see the full changelog for details). > > Can you try disabling the global variable, to see if that makes > a difference (should not be enabled in production)? Untested patch > (against guest kernel) below The following was re-done on a 3.4 guest kernel (previously RHEL kernel): 1-way: tsc: .0315 kvm-clock: .2112 (6.7x) 16-way: tsc: .0432 kvm-clock: .4825 (11.1x) Now with global var disabled: 16-way: kvm-clock: .4628
It is not possible to implement vsyscall support for kvmclock because it would be necessary to write to the "global point" variable in kernel space introduced by commit "x86, paravirt: Add a global synchronization point for pvclock" (from userspace). It is not possible to remove that global variable due to a fundamental characteristic of kvmclock tsc-delta based updates. There is no guarantee that the TSC is synchronized across CPUs on large SMP systems, no matter how reliable and stable individual TSCs are. This means that kvmclock system_time+tsc_timestamp updates must be performed eventually, which in turn requires the global synchronization point to exist.
*** Bug 919899 has been marked as a duplicate of this bug. ***
Marcelo, QE duble-checked this bug, but still have not idea how to verify this bug. would please tell QE how to verify it ? Thanks!
According to comment13, I plan to set this issue as verified. Please add your comment if we missed some testing. Best Regards, Junyi
This request was resolved in Red Hat Enterprise Linux 7.0. Contact your manager or support representative in case you have further questions about the request.