[openbeos] Re: memory beyond 1 gig

  • From: "Jean-Baptiste Queru" <jb@xxxxxxxxx>
  • To: <openbeos@xxxxxxxxxxxxx>
  • Date: Fri, 7 Sep 2001 08:55:15 -0700

> The biggest problem IMO is not the vm structures overflowing, but the fact
that
> _all_ the physical memory is mapped into a portion of the virtual space of
each
> team (in the kernel part, which is limited to 2G).

Exactly.

Here are a few problems you might have (and I probably forgot some) :

-somewhere around 1GB, mapping physical RAM into kernel space
starts to be an issue.
The code that assumes that physical RAM is always mapped must be
re-written, including (but not limited to) the vm code that handles page
tables, which must now map the page directories and access them
through virtual addresses (which involves making that code somewhat
re-entrant)

-beyond 2GB, some 32-bit values may overflow. You need to make
sure that you use unsigned data at all times.

-somewhere around 3.5GB, some of the physical RAM starts to be hidden
from 32-bit PCI devices. This limit is similar to the 16-MB limit of ISA.

-somewhere around the same 3.5GB, you need to enable 36-bit physical
addressing (PAE), and a bunch of internal vm structures and vm code
may have to be re-written to handle the extra bits.

-we might see a point where IA32 desktop machines can eat 64GB of
RAM, but I am not sure that it will ever become an issue for Joe Average
Consumer (IA32 might disappear before we reach that point). And I
would assume that intel would simply add a few address pins to their
CPUs (and the matching bits in the page directories) if it ever became
an issue.

Also, the following problems can appear (and I probably forgot some) :

-somewhere between 512MB and 2GB (depending on the application),
the 2GB part of the address space that is reserved for user-space starts
to be a bit too small. Efforts must be made to shrink kernel-space to
something much smaller. 256MB sounds like a "reasonable" target.
 This means that kernel-space must be able to allocate memory directly
in physical space and map it on-demand (vm structures, page directories,
disk cache, loader cache...).

-(unrelated to the previous one). Even with a 2GB kernel space, and
even without mapping physical memory in it, kernel space can start
to become small. Storing 2GB of data in the disk cache might not be
that unreasonable. Also, the vm structures and the page directories can
start to consume more and more address space, to a point that might
become critical. The solution is the same one as the one in the previous
point.

-Even with a reduced kernel space, you'll eventually reach a point where
a 4GB address space is too small for user-space. You need to allow
user-space to allocate memory in physical space and to map it on demand.

--

Jean-Baptiste Queru <jb@xxxxxxxxx>


Other related posts: