Re: [SLE] 32-bit machines hit physical RAM limit at 4GB?

Per Jessen wrote:
James Knott wrote:

While I don't have the exact details of PAE, in general memory mapping
works by mapping physical memory outside of the normal addressing
range, to an address within that range. This means that only a
portion of that physical address range can be visible at a given time.
An application has to be able to tell the operating system what
portion of the physical memory it wants and also where in address
space it wants it to be located.

Err, no. In Linux and many other OSes with virtual memory, no
application needs to "tell the operating system what portion of the
physical memory it wants" nor "where in address space it wants it to be
located.".
It only needs to say HOW MUCH it wants, and the virtual memory manager
takes care of the rest.

Here's an example of why your application does not need to know about
PAE.
When you install a SUSE 10.1 system on your machine with 1Gb RAM (for
instance), you can pick e.g. the default kernel and no doubt your
system and your applications will run fine. Then you add some more RAM
- let's say you now have 8Gb RAM. To make use of this, you now install
the bigsmp kernel or alternatively you just rebuild your current kernel
with the CONFIG_HIGHMEM64G option enabled. Your applications aren't
touched, yet they run just fine - but of course you can now run a lot
more of them. They don't need to know about how much memory your
system has, nor how it is accessed - again, the virtual memory manager
takes care of that.

Another example - I typically build applications on systems with a lot
less memory than my servers. Maybe 512M, maybe 1Gb. So definitely
without PAE. But these applications run fine on my servers with a lot
more memory, without knowing anything about it. After all, their
address space has not changed. It's still 4Gb per process, perhaps
with a 3Gb/1Gb split for user/kernel.


In another message, I sent a link to a Microsoft description of PAE,
where you'll find things such as:

"Addressing physical memory above 4 GB requires more than the 32 bits of
address offered by the standard operating mode of Intel (32-bit)
processors. To this end, Intel introduced the 36-bit physical addressing
mode called PAE, starting with the Intel Pentium Pro processor.

This article describes some techniques that Microsoft® Windows®
operating systems and several UNIX operating systems use to provide
support to applications using PAE mode addressing. Because processes
running in these environments have 32-bit pointers, the operating system
must manage and present PAE's 36 bits of address in such a way that the
applications can practically use it. The key question is: how does the
operating system solve this problem? The performance, functionality,
simplicity of programming, and reliability of how these issues are
handled will determine the usefulness of the large memory support."


and


"3. Application Windowing
A PAE-enabled operating system can introduce an API to allow a properly
coded application access to physical memory anywhere in the system, even
though it may be above 4 GB. Ideally, the API to allocate "high"
physical memory and create or move the window should be quick and simple
to code. This is highly advantageous for applications that require fast
access to large amounts of data in memory.

Sharing high memory between processes can introduce quite a bit of
complexity into the API and the implementation. Windows avoids this kind
of sharing.

In addition, the support of paging makes the design and implementation
of the operating system much more difficult and makes deterministic
performance more difficult to achieve. Windows avoids paging of high
memory as well."



Without using PAE, a 32 bit app, has no way to tell the OS how much
memory beyond 4 GB it wants. If an app doesn't use the PAE API, it
can't access beyond that 4 GB.

Perhaps you'd better read that article and get back to me.




--
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

Relevant Pages

  • Re: RAM
    ... For applications that are I/O-intensive, ... The 4GT RAM Tuning feature increases the memory ... more than 2 GB of physical memory. ... VirtualAlloc function. ...
    (alt.os.windows-xp)
  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)
  • relic Have you learned how to post yet?
    ... As you have a selective memory, here is the source code for you. ... applications with a 4 GB virtual address space. ... that run on computers with more than 2 GB of physical memory. ... Address Windowing Extensions (AWE) enables applications to address more = ...
    (alt.os.windows-xp)
  • Re: If Macs have no spyware....
    ... First you yammer about being a Mac advocate, then bad mouth me for dumping XP in favor of a Mac. ... Supposedly Microsoft had made a complete code review of its operating system and removed all the buffers which could overflow. ... the fundamental problem is that the basic architecture of Windows has two fatal flaws in its memory management and while these remain in the software the ad hoc patches will never be enough to make Windows a secure operating system. ... These problems are bad enough when dealing with data in the one routine but when the data exists on the stack, it can cause very large problems. ...
    (comp.sys.mac.advocacy)
  • Re: [Lit.] Buffer overruns
    ... > floating point support or a memory expansion option. ... had virtual memory support grafted on. ... > where the modified instruction was fetched from. ... vis-a-vis the official coporate strategic operating system TSS/360. ...
    (sci.crypt)