From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: KVM Processor cache size Date: Tue, 03 Aug 2010 09:25:43 +0300 Message-ID: <4C57B667.2040109@redhat.com> References: <4C56BF6F.9040402@amd.com> <4C56CCFB.204@redhat.com> <4C574559.40509@codemonkey.ws> <4C5749C6.8010901@amd.com> <4C57566D.7000007@codemonkey.ws> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Przywara , Ulrich Drepper , Ricardo Martins , "kvm@vger.kernel.org" To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20485 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755158Ab0HCGZx (ORCPT ); Tue, 3 Aug 2010 02:25:53 -0400 In-Reply-To: <4C57566D.7000007@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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