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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
