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.
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
