From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: KVM Processor cache size Date: Tue, 3 Aug 2010 00:42:14 +0200 Message-ID: <4C5749C6.8010901@amd.com> References: <4C56BF6F.9040402@amd.com> <4C56CCFB.204@redhat.com> <4C574559.40509@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: Ulrich Drepper , Ricardo Martins , "kvm@vger.kernel.org" To: Anthony Liguori Return-path: Received: from tx2ehsobe001.messaging.microsoft.com ([65.55.88.11]:29138 "EHLO TX2EHSOBE001.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754190Ab0HBWmT (ORCPT ); Mon, 2 Aug 2010 18:42:19 -0400 In-Reply-To: <4C574559.40509@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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. 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. Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 488-3567-12