On 08/23/10 19:44, Zachary Amsden wrote: >> I have also looked at time keeping and performance of getimeofday on a >> certain proprietary hypervisor. KVM lags severely here and workloads >> dependent on timestamps are dramatically impacted. Evaluations and >> decisions are made today based on current designs - both KVM and >> product. Severe performance deltas raise a lot of flags. >> > > This is laughably incorrect. Uh, right. > > Gettimeofday is faster on KVM than anything else using TSC based clock > because it passes the TSC through directly. VMware traps the TSC and > is actually slower. Yes, it does trap the TSC to ensure it is increasing. My question regarding trapping on KVM was about to what to expect in terms of overhead. Furthermore, if you add trapping on KVM are TSC reads still faster on KVM? > > Can you please define your "severe performance delta" and tell us your > benchmark methodology? I'd like to help you figure out how it is flawed. I sent you the link in the last response. Here it is again: http://www.mail-archive.com/kvm@xxxxxxxxxxxxxxx/msg07231.html TSC - fast, but has horrible time drifts PIT - horribly slow ACPI PM - horribly slow HPET - did not exist in Nov. 2008, and since has not been reliable in my tests with RHEL4 and RHEL5 kvmclock - does not exist for RHEL4 and not usable on RHEL5 until the update of 5.5 with the fix (I have not retried RHEL5 with the latest maintenance kernel to verify it is stable in my use cases). Take the program from the link above. Run it in a RHEL4 & RHEL5 guest running on VMware for all the clock sources. Somewhere I have the data for these comparisons -- KVM, VMware and bare metal. Same hardware, same OS. The PIT and acpi-PM clock sources are faster on VMware than bare metal. My point is that kvmclock is Red Hat's answer for the future -- RHEL6, RHEL5.Y (whenever it proves reliable). What about the present? What about products based on other distributions newer than RHEL5 but pre-kvmclock? There are a lot of moving windows of what to use as a clock source, not just per major number (RHEL4, RHEL5) but minor number (e.g., TSC stability on RHEL4 -- e.g., https://bugzilla.redhat.com/show_bug.cgi?id=491154) and further maintenance releases (kvmclock requiring RHEL5.5+). That is not very friendly to a product making a transition to virtualization - and with the same code base running bare metal or in a VM. David > > Zach -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
