All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Maximum Physical Memory on 2.4 and ia32
Date: Sun, 01 Dec 2002 18:44:21 -0800	[thread overview]
Message-ID: <3DEAC905.86769170@digeo.com> (raw)
In-Reply-To: 20021202120835.4ecb87fd.sfr@canb.auug.org.au

Stephen Rothwell wrote:
> 
> Hi all,
> 
> This may be a FAQ (but I did search).
> 
> Given this statement by RedHat:
> 
> "RAM Limitations on IA32
> 
> Red Hat Linux releases based on the 2.4 kernel -- including Red Hat Linux
> 7.1, 7.2, 7.3 and Red Hat Linux Advanced Server 2.1 -- support a maximum
> of 16GB of RAM. Previous product announcements from Red Hat suggested that
> Red Hat Linux 7.1 (and by extension, other releases based on the 2.4
> kernel) supported up to 64GB of RAM. A more accurate statement is the
> 2.4-based kernels included in Red Hat Linux 7.1, 7.2, 7.3 and Red Hat
> Linux Advanced Server 2.1 support the hardware extensions that support up
> to 64GB of RAM. This is an important distinction: while the hardware will
> indeed support up to 64GB of physical memory, the operating system design
> limits the supported physical memory to approximately 16GB."
> 
> (http://www.redhat.com/services/techsupport/production/GSS_caveat.html)
> What are the "operating system design limits" that restrict the amount of
> supported memory to 16GB?

It's a practical limit.  The mem_map array alone would consume 720 megabytes,
so you have no normal-zone memory left.

At 16G, mem_map[] consumes 180 megabytes and there's 540ish megabytes
of normal zone left for general use.

Even at this 20:1 highmem:lowmem ratio, the system will be struggling.
Any time you have normal-zone data structures which are pinned by
pages, the maths gets you in the end.

buffer_heads, pagetable pages, radix-tree nodes, pte_chains and inodes
are normal-zone data structures which, depending on the kernel version,
may be pinned into the normal zone by highmem pages.

In 2.5, with ext2's no-buffer-head option, shared pagetables, highpte,
with your fingers crossed and the wind in the south east, 32G might
be practical.

  reply	other threads:[~2002-12-02  2:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-02  1:08 Maximum Physical Memory on 2.4 and ia32 Stephen Rothwell
2002-12-02  2:44 ` Andrew Morton [this message]
2002-12-02  6:48   ` Martin J. Bligh
2002-12-02  7:04 ` William Lee Irwin III

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=3DEAC905.86769170@digeo.com \
    --to=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.