Re: KVM Processor cache size

[Dor Laor <dlaor@redhat.com>]

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