From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/2] KVM: MMU: Make pte_list_desc fit cache lines well Date: Sun, 08 Apr 2012 16:09:58 +0300 Message-ID: <4F818E26.8000809@redhat.com> References: <20120321234823.55f84cef3a2b749c2a93f012@gmail.com> <20120321234939.326822b0552d5c463acda22d@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mtosatti@redhat.com, kvm@vger.kernel.org To: Takuya Yoshikawa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37176 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755300Ab2DHNKB (ORCPT ); Sun, 8 Apr 2012 09:10:01 -0400 In-Reply-To: <20120321234939.326822b0552d5c463acda22d@gmail.com> Sender: kvm-owner@vger.kernel.org List-ID: On 03/21/2012 04:49 PM, Takuya Yoshikawa wrote: > From: Takuya Yoshikawa > > We have PTE_LIST_EXT + 1 pointers in this structure and these 40/20 > bytes do not fit cache lines well. Furthermore, some allocators may > use 64/32-byte objects for the pte_list_desc cache. > > This patch solves this problem by changing PTE_LIST_EXT from 4 to 3. > > For shadow paging, the new size is still large enough to hold both the > kernel and process mappings for usual anonymous pages. For file > mappings, there may be a slight change in the cache usage. > > Note: with EPT/NPT we almost always have a single spte in each reverse > mapping and we will not see any change by this. > > @@ -135,8 +135,6 @@ module_param(dbg, bool, 0644); > #define PT64_PERM_MASK (PT_PRESENT_MASK | PT_WRITABLE_MASK | PT_USER_MASK \ > | PT64_NX_MASK) > > -#define PTE_LIST_EXT 4 > - > #define ACC_EXEC_MASK 1 > #define ACC_WRITE_MASK PT_WRITABLE_MASK > #define ACC_USER_MASK PT_USER_MASK > @@ -151,6 +149,9 @@ module_param(dbg, bool, 0644); > > #define SHADOW_PT_INDEX(addr, level) PT64_INDEX(addr, level) > > +/* make pte_list_desc fit well in cache line */ > +#define PTE_LIST_EXT 3 > + > struct pte_list_desc { > u64 *sptes[PTE_LIST_EXT]; > struct pte_list_desc *more; We could go even further and have 4 pointers, and use bit 0 to decide whether it's a next pointer or an sptep. Not sure it's worth the extra complexity. -- error compiling committee.c: too many arguments to function