[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <518217D1.3070008@valvesoftware.com>
Date: Thu, 2 May 2013 00:37:53 -0700
From: "Pierre-Loup A. Griffais" <pgriffais@...vesoftware.com>
To: Rik van Riel <riel@...hat.com>
CC: Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
<sonnyrao@...omium.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm,x86: limit 32 bit kernel to 12GB memory
Reviewed-by: Pierre-Loup A. Griffais <pgriffais@...vesoftware.com>
On 05/01/2013 07:46 PM, Rik van Riel wrote:
> On Wed, 1 May 2013 21:34:26 -0400
> Steven Rostedt <rostedt@...dmis.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@...hat.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 */
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists