On Tue, 2010-12-14 at 15:34 +0200, Avi Kivity wrote: > On 12/14/2010 02:09 PM, Ulrich Obergfell wrote: > > Hi, > > > > This is an RFC through which I would like to get feedback on how the > > idea of in-kernel PM Timer would be received. > > > > The current implementation of PM Timer emulation is 'heavy-weight' > > because the code resides in qemu userspace. Guest operating systems > > that use PM Timer as a clock source (for example, older versions of > > Linux that do not have paravirtualized clock) would benefit from an > > in-kernel PM Timer emulation. > > > > Parts 1 thru 4 of this RFC contain experimental source code which > > I recently used to investigate the performance benefit. In a Linux > > guest, I was running a program that calls gettimeofday() 'n' times > > in a loop (the PM Timer register is read during each call). With > > in-kernel PM Timer, I observed a significant reduction of program > > execution time. > > > > The experimental code emulates the PM Timer register in KVM kernel. > > All other components of ACPI PM remain in qemu userspace. Also, the > > 'timer carry interrupt' feature is not implemented in-kernel. If a > > guest operating system needs to enable the 'timer carry interrupt', > > the code takes care that PM Timer emulation falls back to userspace. > > However, I think the design of the code has sufficient flexibility, > > so that anyone who would want to add the 'timer carry interrupt' > > feature in-kernel could try to do so later on. > > > > What is the motivation for this? Are there any important guests that > use the pmtimer? Avi, All older RHEL and Windows, for example, would benefit for this. > If anything I'd expect hpet or the Microsoft synthetic timers to be a > lot more important. True. But also a lot more work. Implementing just the pm timer counter - not the whole of it - in kernel, gives us a lot of gain with not very much effort. Patch is pretty simple, as you can see, and most of it is even code to turn it on/off, etc. -- 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
