[lkml]   [2010]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [KVM timekeeping 26/35] Catchup slower TSC to guest rate
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.


 \ /
  Last update: 2010-09-08 00:17    [W:0.037 / U:6.592 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site