> Long running guests on a large farm shouldn't expect to stay on the same > host they were booted on.
If they change frequently and the vendors are even matched in the farm their chance of running "fast" again will be quite good. The only worst case would be to start on one vendor, run for a short time there and then spend all the remaining time on the other. Most other cases would be better. Also again I wouldn't expect the impact to be that dramatic. While there are some workloads which are syscall latency sensitive (and not rely on the vsyscalls) a lot of others are not. > But at least for Linux, if we notify the > guest telling it to retune (which can include the vsyscall path) we can > avoid the cost entirely. Hmm, we discussed something like this some time ago anyways (add a way to rescan CPUID features) because there are microcode updates around that change some (relatively obscure) CPUID features. But doing it fully general would be likely quite intrusive. You would need to rewrite the CPU initialization code and some other code in a callback like matter like the PCI code does for hotplug. I doubt doing that would be worth the effort in real performance gains. -Andi -- [EMAIL PROTECTED] -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
