From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759903Ab3EBCqZ (ORCPT ); Wed, 1 May 2013 22:46:25 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50777 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752571Ab3EBCqV (ORCPT ); Wed, 1 May 2013 22:46:21 -0400 Date: Wed, 1 May 2013 22:46:04 -0400 From: Rik van Riel To: Steven Rostedt Cc: Linus Torvalds , "Pierre-Loup A. Griffais" , Johannes Weiner , Linux Kernel Mailing List , sonnyrao@chromium.org, KAMEZAWA Hiroyuki , Andrew Morton Subject: [PATCH] mm,x86: limit 32 bit kernel to 12GB memory Message-ID: <20130501224604.21ebc42a@annuminas.surriel.com> In-Reply-To: <20130502013426.GC9583@home.goodmis.org> References: <517B1153.8000401@valvesoftware.com> <517B2FB4.30605@redhat.com> <20130427024248.GA1229@cmpxchg.org> <517EEBD1.503@valvesoftware.com> <517F14D1.3070307@redhat.com> <20130502013426.GC9583@home.goodmis.org> Organization: Red Hat, Inc. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 May 2013 21:34:26 -0400 Steven Rostedt wrote: > On Mon, Apr 29, 2013 at 08:48:17PM -0400, Rik van Riel wrote: > > > > It could also print out a friendly message, to > > inform the user they should upgrade to a 64 bit > > kernel to enjoy the use of all of their memory. > > Oh, oh, oh!!! Can we use my message: > > http://lwn.net/Articles/501769/ > > OK, maybe it's not so friendly ;-) Here's a somewhat friendlier one. Printing out the total amount of memory in the system may give them some extra motivation to upgrade to a 64 bit kernel :) ---8<---- Subject: mm,x86: limit 32 bit kernel to 12GB memory Running 32 bit kernels on very large memory systems is a recipe for disaster, due to fundamental architectural limits in both Linux and the hardware. Moreover, all modern hardware with large memory supports 64 bits. However, many users continue using 32 bit kernels, and end up encountering stability and performance problems as a result. It may be better to save those people the frustration of stability issues by limiting memory on a 32 bit kernel to 12GB (about the upper limit that still works right), and printing a friendly reminder that they really should be using a 64 bit kernel. Signed-off-by: Rik van Riel --- arch/x86/include/asm/setup.h | 1 + arch/x86/mm/init_32.c | 11 +++++++++++ 2 files changed, 12 insertions(+) diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h index b7bf350..79de6bf 100644 --- a/arch/x86/include/asm/setup.h +++ b/arch/x86/include/asm/setup.h @@ -14,6 +14,7 @@ */ #define MAXMEM_PFN PFN_DOWN(MAXMEM) #define MAX_NONPAE_PFN (1 << 20) +#define MAX_PAE_PFN (3 << 20) #endif /* __i386__ */ diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c index 3ac7e31..e35b3f5 100644 --- a/arch/x86/mm/init_32.c +++ b/arch/x86/mm/init_32.c @@ -600,6 +600,12 @@ static void __init lowmem_pfn_init(void) #define MSG_HIGHMEM_TRIMMED \ "Warning: only 4GB will be used. Use a HIGHMEM64G enabled kernel!\n" + +#define MSG_HIGHMEM_INSANE \ + "Warning: 32 bit kernels on large memory systems have problems.\n" \ + "Limiting memory to 12GB for system stability.\n" \ + "Use a 64 bit kernel to access all %lu MB of memory.\n" + /* * We have more RAM than fits into lowmem - we try to put it into * highmem, also taking the highmem=x boot parameter into account: @@ -634,6 +640,11 @@ static void __init highmem_pfn_init(void) max_pfn = MAX_NONPAE_PFN; printk(KERN_WARNING MSG_HIGHMEM_TRIMMED); } +#else /* !CONFIG_HIGHMEM64G */ + if (max_pfn > MAX_PAE_PFN) { + printk(KERN_WARNING MSG_HIGHMEM_INSANE, max_pfn>>8); + max_pfn = MAX_PFN; + } #endif /* !CONFIG_HIGHMEM64G */ #endif /* !CONFIG_HIGHMEM */ }