On 09/06/2010 05:44 PM, Dong, Eddie wrote: > Zachary: > Will you extend the logic to cover the situation when the guest runs at higher than the guest rate but the PCPU is over committed. In that case, likely we can use the time spent when the VCPU is scheduled out to catch up as well. Of course if the VCPU scheduled out time is not enough to compensate the cycles caused by fast host TSC (exceeding a threahold), we will eventually have to fall back to trap and emulation mode. > It is possible to do this, but it is rather dangerous. We can't let the guest clock accelerate without bounds. We could put a limit on the maximum overrun the TSC is allowed to reach, and then switch into trapping mode, but this pre-supposes we will actually get an interrupt in time. A CPU heavy guest with little host activity could easily overrun much further than we would like unless we have a way to reliably trigger interrupts near the time of maximum allowed overrun. So, first, we must have a way to get such interrupts; this is needed anyway, for the catchup case, we have a similar problem with underrun which must be addressed. It's quite possible to add the mode you describe once that feature is in, but it also adds even more complexity to an already intricate clock system (which is one of the problem with the latter part of this patch series). Second, this mode of operation is incompatible with SMP guests under all circumstances. SMP guests with mismatched clock speeds must always run in trapping mode, as it is not possible to synchronize the catchup / trap switching without extremely heavyweight measures (use IPI wakeup). Those mechanisms will not only cost more than the trapping overhead (future, faster systems, and larger, more parallel systems), but they will also damage host performance (unneeded wakeups when other VCPUs are not scheduled). Unless, of course, we gang-schedule... but that is a difficult change and a very different mode of operation. Getting rid of TSC trap overhead on systems with non-constant TSC isn't a sufficient motivation for that kind of design change. 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
