From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Subject: Re: [PATCH 1/2] kvm/e500v2: Remove shadow tlb Date: Thu, 09 Sep 2010 11:13:38 -0700 Message-ID: <4C8923D2.5070308@mentor.com> References: <1283938806-2981-1-git-send-email-yu.liu@freescale.com> <1283938806-2981-2-git-send-email-yu.liu@freescale.com> <4C87B491.2050002@mentor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, kvm-ppc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, agraf-l3A5Bk7waGM@public.gmane.org To: Liu Yu-B13201 Return-path: In-Reply-To: Sender: kvm-ppc-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: kvm.vger.kernel.org On 09/09/2010 04:16 AM, Liu Yu-B13201 wrote: > Yes, it's hard to resume TLB0. We only resume TLB1 in previous code. > But TLB1 is even more smaller (13 free entries) than 440, > So that it still has little possibility to get hit. > thus the resumption is useless. > The only reason hits are unlikely in TLB1 is because you still don't have large page support in the host. Once you have that, you can use TLB1 for large guest mappings, and it will become extremely likely that you get hits in TLB1. This is true even if the guest wants 256MB but the host supports only e.g. 16MB large pages, and must split the guest mapping into multiple large host pages. When will you have hugetlbfs for e500? That's going to make such a dramatic difference, I'm not sure it's worth investing time in optimizing the MMU code until then. Hollis Blanchard Mentor Graphics, Embedded Systems Division