public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
To: Rik van Riel <riel@redhat.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	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: Re: [PATCH] mm,x86: limit 32 bit kernel to 12GB memory
Date: Thu, 2 May 2013 00:37:53 -0700	[thread overview]
Message-ID: <518217D1.3070008@valvesoftware.com> (raw)
In-Reply-To: <20130501224604.21ebc42a@annuminas.surriel.com>

Reviewed-by: Pierre-Loup A. Griffais <pgriffais@valvesoftware.com>

On 05/01/2013 07:46 PM, Rik van Riel wrote:
> 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  8:01 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             ` [PATCH] mm,x86: limit 32 bit kernel to 12GB memory Rik van Riel
2013-05-02  7:37               ` Pierre-Loup A. Griffais [this message]
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=518217D1.3070008@valvesoftware.com \
    --to=pgriffais@valvesoftware.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.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