Re: [PATCH 0/6] KVM support for TSC scaling
From: Avi Kivity
Date: Tue Feb 22 2011 - 05:11:53 EST
On 02/21/2011 07:28 PM, Roedel, Joerg wrote:
> - what's the cost of wrmsr(TSC_MULT)?
Hard to tell by now because I only have numbers for pre-production
hardware.
Can you ask your hardware people what the cost will likely be? msrs are
often expensive, and here we have two in the lightweight exit path.
> There are really two ways to implement this feature. One is fully
> generic, like you did. The other is to implement it at the host level -
> have a sysfs file and/or kernel parameter for the desired tsc frequency,
> write it once, and forget about it. Trust management to set the host
> tsc frequency to the same value on all hosts in a migration cluster.
The motivation here is mostly the flexibility. Scale the TSC for the
whole migration cluster only makes sense if all hosts there support the
feature. But the most likely scenario is that existing migration
clusters will be extended by new machines and guests will be migrated
there. And these guests should be able to see the same TSC frequency on
the new host as the had on the old one. The older machines in the
cluster may even have different TSC frequencys. With this flexible
implementation those scenarios are possible. A host-wide setting for the
scaling will make the feature useless in those (common) scenarios.
This doesn't really work, since we don't know on what host the TSC
calibration loop ran:
- start guest on host H1
- migrate it around, now it's on host H2
- guest reboots, reruns calibration loop
- migrate it around some more, now it's on host H3
- migrate to host with tsc multiplier Hnew
So, what should we set the multiplier to? H1, H2, or H3's tsc rate?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/