[openbeos] Re: memory beyond 1 gig

  • From: Michael Praschl <m.praschl@xxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Fri, 07 Sep 2001 16:09:07 +0200

was this caused by somebody who said, 32bit should be enough for anyone?
;-)

regards,
Michael

At 15:57 07.09.2001 +0200, you wrote:

>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=
=20
>that
>_all_ the physical memory is mapped into a portion of the virtual space of=
=20
>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=20
>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=E7ois.
>
>En r=E9ponse =E0 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: