public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil>
To: ttabi@interactivesi.com, linux-kernel@vger.kernel.org
Subject: Re: What is the truth about Linux 2.4's RAM limitations?
Date: Tue, 10 Jul 2001 13:12:54 -0500 (CDT)	[thread overview]
Message-ID: <200107101812.NAA01171@tomcat.admin.navo.hpc.mil> (raw)

Timur Tabi <ttabi@interactivesi.com>:
> Jesse Pollard wrote:
> >>So what are the limits without using PAE? Here I'm still having a little
> >>problem finding definitive answers but ...
> >>
> >3 GB. Final answers are in the FAQ, and have been discussed before. You can
> >also look in the Intel 80x86 CPU specifications.
> >
> >The only way to exceed current limits is via some form of segment register usage
> >which will require a different compiler and a replacement of the memory
> >architecture of x86 Linux implementation.
> >
> 
> Are you talking about using 48-bit pointers?
> 
> (48-bit pointers, aka 16:32 pointers, on x86 are basically "far 32-bit 
> pointers".  That is, each pointer is stored as a 48-bit value, where 16 
> bits are for the selector/segment, and 32 bits are for the offset.

That sounds right - I'm not yet fully familiar with the low level intel
x86 design yet. There is also (based on list email) a limit to how
many page tables can be active. Two is desirable (one system, one user)
but the x86 design only has one. This causes Linux (and maybe others too)
to split the 32 bit range into a 3G (user) and 1G (system) address ranges
to allow the page cache/cpu cache to work in a more optimum manner. If
the entire page table were given to a user, then a full cache flush would
have to be done on every context switch and system call. That would be
very slow, but would allow a full 4G address for the user.

The use of 48 bit addresses has the same problem. Doing the remapping for
the segment + offset requires flushing the cache as well (the cache seems
to be between the segment registers and the page tables - not sure, not
necessarily coreect... I still have to get the new CPU specs...)

Any body want to offer a full reference? Or a tutorial on Intel addressing
capability?.


-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

             reply	other threads:[~2001-07-10 18:13 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-10 18:12 Jesse Pollard [this message]
2001-07-10 18:22 ` What is the truth about Linux 2.4's RAM limitations? Jonathan Lundell
2001-07-10 18:28 ` Brian Gerst
2001-07-10 18:43   ` Chris Wedgwood
2001-07-10 19:35     ` Brian Gerst
  -- strict thread matches above, loose matches on Subject: below --
2001-07-11  4:31 alad
2001-07-10 21:49 Jesse Pollard
2001-07-10 22:07 ` Jonathan Lundell
2001-07-10 18:38 Jesse Pollard
2001-07-10 19:14 ` Mark H. Wood
2001-07-09 21:29 Jesse Pollard
2001-07-10 17:01 ` Timur Tabi
     [not found] <Pine.LNX.4.32.0107091250170.25061-100000@maus.spack.org.suse.lists.linux.kernel>
2001-07-09 21:03 ` Andi Kleen
2001-07-09 20:01 Adam Shand
2001-07-09 21:15 ` Brian Gerst
2001-07-09 21:18 ` Rik van Riel
2001-07-09 22:17 ` Matti Aarnio
2001-07-10 13:49   ` Chris Wedgwood
2001-07-10 17:03     ` Timur Tabi
2001-07-10 17:35       ` Richard B. Johnson
2001-07-10 18:01         ` Timur Tabi
2001-07-10 18:08         ` Jonathan Lundell
2001-07-10 18:45           ` Richard B. Johnson
2001-07-10 19:26             ` Jonathan Lundell
2001-07-10 23:56             ` Jesse Pollard
2001-07-10 20:19         ` Malcolm Beattie
2001-07-10  3:01 ` jlnance
2001-07-10  3:29   ` Michael Bacarella
2001-07-16  8:37   ` Ingo Oeser

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=200107101812.NAA01171@tomcat.admin.navo.hpc.mil \
    --to=pollard@tomcat.admin.navo.hpc.mil \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ttabi@interactivesi.com \
    /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