From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH] KVM: PPC: E500: Support hugetlbfs Date: Mon, 26 Sep 2011 15:28:25 -0500 Message-ID: <4E80E069.5080302@freescale.com> References: <1316475344-12033-1-git-send-email-agraf@suse.de> <4E78D35A.9000301@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: , To: Alexander Graf Return-path: In-Reply-To: Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 09/24/2011 02:44 AM, Alexander Graf wrote: > On 20.09.2011, at 19:54, Scott Wood wrote: >> On 09/19/2011 06:35 PM, Alexander Graf wrote: >>> + asm (PPC_CNTLZL "%0,%1" : "=r" (lz) : "r" (psize)); >>> + tsize = min(21 - lz, tsize); >> >> No need to open-code the cntlz and subtract-from-21: >> >> tsize = min(ilog2(psize) - 10, tsize); >> >> /* >> * e500 doesn't implement the lowest tsize bit, >> * or 1K pages. >> */ >> tsize = max(BOOK3E_PAGESZ_4K, tsize & ~1); >> >> There's still an open-coded subtraction of 10, but that relates more >> straightforwardly to the definition of tsize (and could be factored out >> into a size-to-tsize function). > > Yeah, no need to micro-optimized those few bits. The reason I used the asm statement was that I copied the hugetlbfs code which does it that way :). The "21 - lz" thing is broken on 64-bit, FWIW. It works by chance in the hugetlbfs code (and in settlbcam) because it results in tsize being too low by 32, which only affects bits that subsequently get masked off. >>> } >>> >>> up_read(¤t->mm->mmap_sem); >>> } >>> >>> if (likely(!pfnmap)) { >>> + unsigned long tsize_pages = 1 << (tsize - 2); >> >> 1 << (tsize + 10 - PAGE_SHIFT); > > Are we getting variable page sizes anytime soon? Will change it nevertheless, just curious :). Nothing imminent on our chips AFAIK, but there's some 64K page support in Linux for IBM's book3e chips, and it's not nice to hardcode (especially in a hidden way) regardless. -Scott