On 12/14/10 14:46, Anthony Liguori wrote: > On 12/14/2010 01:54 PM, David S. Ahern wrote: >> >> On 12/14/10 12:49, Anthony Liguori wrote: >> >>> But that doesn't tell you what the impact is in real world workloads. >>> Before we start pushing all device emulation into the kernel, we need to >>> quantify how often gettimeofday() is really called in real workloads. >>> >> The workload that inspired that example program at its current max load >> calls gtod upwards of 1000 times per second. The overhead of >> gettimeofday was the biggest factor when comparing performance to bare >> metal and esx. That's why I wrote the test program --- boils a complex >> product/program to a single system call. >> > > So the absolute performance impact was on the order of what? At the time I did the investigations (18-24 months ago) KVM was on the order of 15-20% worse for a RHEL4 based workload and the overhead appeared to be due to the PIT or PM timer as the clock source. Switching the clock to the TSC brought the performance on par with bare metal, but that route has other issues. > > The difference in CPU time of a light weight vs. heavy weight exit > should be something like 2-3us. That would mean 2-3ms of CPU time at a > rate of 1000 per second. The PIT causes 3 VMEXITs for each gettimeofday (get_offset_pit in RHEL4): /* timer count may underflow right here */ outb_p(0x00, PIT_MODE); /* latch the count ASAP */ ... count = inb_p(PIT_CH0); /* read the latched count */ ... count |= inb_p(PIT_CH0) << 8; ... David > > That should be pretty much in the noise. > > There are possibly second order effects that might make a large impact > such as contention with the qemu_mutex. It's worth doing > experimentation to see if a non-mutex acquiring fast path in userspace > also resulted in a significant performance boost. > > Regards, > > Anthony Liguori > >> David >> >> >>> Regards, >>> >>> Anthony Liguori >>> >>> >>>> What's the relative speed of the in-kernel pmtimer compared to the PIT? >>>> >>>> David >>>> >>>> >>> > -- 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
