[openbeos] Re: memory beyond 1 gig
- From: revol@xxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 07 Sep 2001 15:57:15 +0200 (MEST)
Grrrr, Opera crashed on me when I composed the reply...
What was I saying...
Oh yes:
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).
This trick is used in BeOs (and also in AtheOS) to ease writing some kernel
routines.
So what do you think will happen if you have 4G of RAM ???
it will just try to map your 4G to the 2G space it is allowed to use...
Must-reads:
http://www.benews.com/story/3995 Kurt Skauen interview on BeNews telling about
the 2GB problem
another which describes the virtual space organisation but I can't get
my hands on this one,
http://www-classic.be.com/aboutbe/benewsletter/volume_II/Issue25.html
quite old, about virtual/phys spaces
http://www-classic.be.com/aboutbe/benewsletter/article_index.html
An @ I advise you to bookmark as it has a lot of infos :)
See you,
François.
En réponse à Marcus Overhagen <dos4gw@xxxxxx>:
>
> On Thu, 06 Sep 2001 06:00:21 PM, "p willis" <p.willis@xxxxxxxxx>
> wrote:
>
> >It's pretty easy to make a flat 32 bit memory model that accesses the
> full 4
> >gigs *plus* with some additional virtual paging code the model can be
> extended to
> >super-pages or 4 gig blocks (or parts of blocks) swapped from the HD.
>
> I'm not sure if you understand the concept of virtual memory, and the
> problem.
> Each application has it's own 4GB virtual address space, and into this
> virtual space
> physical memory is mapped in (or harddisk memory, paged in/out), while
> Be decided
> to use some space in the virtual adresses of each process for the
> kernel.
>
> The problem seems to be that the current BeOS kernel's internal data
> structures are not
> large enough to support more than 1 GB physical memory currently.
>
>
> >Just make sure to use 64 bit counters in all your structs so that when
> BeOS
> >requires porting to wider architecture the underlying framework can
> support
> >the move.
> No, don't do this. continue to use normal pointers.
> While a void * is now 32 bit, it will be 64 bit then.
>
> But please stop casting a pointer into an int, or worse, into an
> int32.
> This would break your program one pointers get 64 bits wide.
>
>
> regards
> Marcus
>
>
Other related posts:
