linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	sonnyrao@chromium.org,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: [PATCH] mm,x86: limit 32 bit kernel to 12GB memory
Date: Wed, 1 May 2013 22:46:04 -0400	[thread overview]
Message-ID: <20130501224604.21ebc42a@annuminas.surriel.com> (raw)
In-Reply-To: <20130502013426.GC9583@home.goodmis.org>

On Wed, 1 May 2013 21:34:26 -0400
Steven Rostedt <rostedt@goodmis.org> 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 <riel@redhat.com>
---
 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 */
 }

  reply	other threads:[~2013-05-02  2:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-26 23:44 IO regression after ab8fabd46f on x86 kernels with high memory Pierre-Loup A. Griffais
2013-04-27  1:53 ` Rik van Riel
2013-04-27  2:42   ` Johannes Weiner
2013-04-29 21:53     ` Pierre-Loup A. Griffais
2013-04-29 22:03       ` Linus Torvalds
2013-04-29 22:08         ` Pierre-Loup A. Griffais
2013-05-02  4:37           ` Sonny Rao
2013-04-30  0:48         ` Rik van Riel
2013-04-30  1:06           ` Pierre-Loup A. Griffais
2013-05-02  1:34           ` Steven Rostedt
2013-05-02  2:46             ` Rik van Riel [this message]
2013-05-02  7:37               ` [PATCH] mm,x86: limit 32 bit kernel to 12GB memory Pierre-Loup A. Griffais
2013-05-02 20:03               ` Linus Torvalds
2013-05-11  9:16                 ` Yuhong Bao
2013-05-08 19:10         ` IO regression after ab8fabd46f on x86 kernels with high memory H. Peter Anvin
2013-06-03  1:17           ` Yuhong Bao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130501224604.21ebc42a@annuminas.surriel.com \
    --to=riel@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pgriffais@valvesoftware.com \
    --cc=rostedt@goodmis.org \
    --cc=sonnyrao@chromium.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).