Mailinglist Archive: opensuse (3605 mails)
| < Previous | Next > |
Re: [SLE] 32-bit machines hit physical RAM limit at 4GB?
- From: "Bryan J. Smith" <b.j.smith@xxxxxxxx>
- Date: Mon, 12 Jun 2006 07:57:44 -0400
- Message-id: <1150113465.20685.245.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Mon, 2006-06-12 at 13:32 +0200, Per Jessen wrote:
> Would a Linux application even be able to use PAE by itself?
> Does the kernel provide that option/interface?
Yes. It's really a _complex_ discussion. And my answer below is
_still_ a _mega_-simplification.
On x86, the kernel has various code to do this, along with GCC
compile-time/directives. Applications that want to address more than
1-3GiB (depending on the model) of user-space memory have to be built
differently. It's _never_ a matter of getting access to _all_ 4GiB of
memory, even if the pointers are capable of (or being rationalized to)
address upto 32-bit/4GiB. This is in _addition_ to how the
kernel-processor actually do PAE (36-bit) -- which is a _serious_
performance hit.
On x86-64, the kernel does even a crapload more. It provides the new
"flat" 64-bit address model to the "Long Mode" 48-bit/256TiB pointer
model, as well as uses a 7-layer PAE mode (52-bit). So _all_ programs
can use it -- flat 32-bit to 1/2/3GiB user, >4GiB x86 object code, as
well as new 48-bit "Long Mode" applications. There is also a major
reduction in performance hit for even legacy apps built against the old
PAE (36-bit) model.
--
Bryan J. Smith Professional, technical annoyance
mailto:b.j.smith@xxxxxxxx http://thebs413.blogspot.com
-------------------------------------------------------
Illegal Immigration = "Representation Without Taxation"
--
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@xxxxxxxx
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@xxxxxxxx
> Would a Linux application even be able to use PAE by itself?
> Does the kernel provide that option/interface?
Yes. It's really a _complex_ discussion. And my answer below is
_still_ a _mega_-simplification.
On x86, the kernel has various code to do this, along with GCC
compile-time/directives. Applications that want to address more than
1-3GiB (depending on the model) of user-space memory have to be built
differently. It's _never_ a matter of getting access to _all_ 4GiB of
memory, even if the pointers are capable of (or being rationalized to)
address upto 32-bit/4GiB. This is in _addition_ to how the
kernel-processor actually do PAE (36-bit) -- which is a _serious_
performance hit.
On x86-64, the kernel does even a crapload more. It provides the new
"flat" 64-bit address model to the "Long Mode" 48-bit/256TiB pointer
model, as well as uses a 7-layer PAE mode (52-bit). So _all_ programs
can use it -- flat 32-bit to 1/2/3GiB user, >4GiB x86 object code, as
well as new 48-bit "Long Mode" applications. There is also a major
reduction in performance hit for even legacy apps built against the old
PAE (36-bit) model.
--
Bryan J. Smith Professional, technical annoyance
mailto:b.j.smith@xxxxxxxx http://thebs413.blogspot.com
-------------------------------------------------------
Illegal Immigration = "Representation Without Taxation"
--
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@xxxxxxxx
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@xxxxxxxx
| < Previous | Next > |