On 08/03/2010 02:36 AM, Anthony Liguori wrote:
On 08/02/2010 05:42 PM, Andre Przywara wrote:
Anthony Liguori wrote:
On 08/02/2010 08:49 AM, Ulrich Drepper wrote:
glibc uses the cache size information returned by cpuid to perform
optimizations. For instance, copy operations which would pollute too
much of the cache because they are large will use non-temporal
instructions. There are real performance benefits.
I imagine that there would be real performance problems from doing
live migration with -cpu host too if we don't guarantee these values
remain stable across migration...
Again, -cpu host is not meant to be migrated.
Then it needs to prevent migration from happening. Otherwise, it's a bug
waiting to happen.
There are other virtualization use cases than cloud-like server
virtualization. Sometimes users don't care about migration (or even
the live version), but want full CPU exposure for performance reasons
(think of virtualizing Windows on a Linux desktop).
I agree that -cpu host and migration should be addressed, but only to
a certain degree. And missing migration experience should not be a
road blocker for -cpu host.
When we can reasonably prevent it, we should prevent users from shooting
themselves in the foot. Honestly, I think -cpu host is exactly what you
would want to use in a cloud. A lot of private clouds and even public
clouds are largely based on homogenous hardware.
There are two good solutions for that:
a. keep adding newer -cpu definition like the Penryn, Nehalem,
Opteron_gx, so newer models will be abstracted as similar to the
physical properties
b. Use strict flag with -cpu host and pass the info with the live
migration protocol.
Our live migration protocol can do better job with validation the
cmdline and the current set of devices/hw on the src/dst and fail
migration if there is a diff. Today we relay on libvirt for that,
another mechanism will surely help, especially for -cpu host.
The goodie is that there won't be a need to wait for the non-live
migration part, and more cpu cycles will be saved.
I actually think the case where you want to migrate between heterogenous
hardware is grossly overstated.
Regards,
Anthony Liguori
Regards,
Andre.
--
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
--
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
