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:15:47 +0200 Message-ID: <4C574393.80608@amd.com> References: <4C56BF6F.9040402@amd.com> <4C56CCFB.204@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: Ricardo Martins , "kvm@vger.kernel.org" To: Ulrich Drepper Return-path: Received: from va3ehsobe004.messaging.microsoft.com ([216.32.180.14]:55524 "EHLO VA3EHSOBE004.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752192Ab0HBWPx (ORCPT ); Mon, 2 Aug 2010 18:15:53 -0400 In-Reply-To: <4C56CCFB.204@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Ulrich Drepper wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/02/2010 05:51 AM, Andre Przywara wrote: >> Do you have a use case for the cache size or is this just out of curiosity? > > 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. Thanks for pointing this out. Do you have an idea which benchmark could show the impact of an incorrect cache size? Microbenchmarks would be OK, as long as it can convince maintainers ;-) > Even the synthetic > CPU provided by qemu should have a more realistic value. What would you recommend as a more realistic value? For AMD it is currently 64K/64K C/D for L1 and 512KB for L2, for Intel 32K/32K C/D for L1 and 4MB for L2. I think the 32KB shown in the original post are some kind of a bug, Ricardo, can you reproduce this? Can you post the command line and the used qemu version ($ qemu --version) Regards, Andre. -- Andre Przywara AMD-Operating System Research Center (OSRC), Dresden, Germany Tel: +49 351 488-3567-12