From patchwork Fri Aug 17 14:57:09 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Bader X-Patchwork-Id: 178233 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id 561F22C0092 for ; Sat, 18 Aug 2012 00:57:30 +1000 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1T2NzF-0000dh-Qz; Fri, 17 Aug 2012 14:57:21 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1T2Nz5-0000Ww-W3 for kernel-team@lists.ubuntu.com; Fri, 17 Aug 2012 14:57:12 +0000 Received: from p5b2e3c3b.dip.t-dialin.net ([91.46.60.59] helo=canonical.com) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1T2Nz5-0000hk-Oa for kernel-team@lists.ubuntu.com; Fri, 17 Aug 2012 14:57:11 +0000 From: Stefan Bader To: kernel-team@lists.ubuntu.com Subject: [PATCH] Subject: [Quantal SAUCE] x86/mm: Fix 64bit size of mapping tables Date: Fri, 17 Aug 2012 16:57:09 +0200 Message-Id: <1345215429-18570-1-git-send-email-stefan.bader@canonical.com> X-Mailer: git-send-email 1.7.9.5 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com This will also fix some issues with crash-kexec not working anymore on 64bit systems. And I hope to get hold of some real humans at Plumbers the week after next. But meanwhile... -Stefan --- From d370223977f1e0b4218cb978f480ff4220344eb0 Mon Sep 17 00:00:00 2001 From: Stefan Bader Date: Fri, 17 Aug 2012 15:07:27 +0200 Subject: [PATCH] UBUNTU: SAUCE: (no-up) x86/mm: Fix 64bit size of mapping tables commit 722bc6b16771ed80871e1fd81c86d3627dda2ac8 x86/mm: Fix the size calculation of mapping tables introduced a change to adapt size reserved for the initial mapping tables for the first 2/4M range being still 4K. This would looks necessary because that range is also covered by MTRRs and it would be bad (performance issues at least) to have MTRR ranges not aligned with the page boundaries. However there does not seem to be a reason to handle 32bit and 64bit differently. Which is exaclty what the upstream code (even now) does. While trying to get into discussion with upstream about the right way to fix this, we should at least make the calculations consistent. IOW, for 64bit the first range _is_ 2M pages (or at least not 4K), so the additional PTEs are not needed. With this applied the size of the initial page tables went from 4M to 16K on a VM that had 2G of memory. Signed-off-by: Stefan Bader --- arch/x86/mm/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index bc4e9d8..6219612 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -60,10 +60,10 @@ static void __init find_early_table_space(struct map_range *mr, unsigned long en extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT); #ifdef CONFIG_X86_32 extra += PMD_SIZE; -#endif /* The first 2/4M doesn't use large pages. */ if (mr->start < PMD_SIZE) extra += mr->end - mr->start; +#endif ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT; } else