[openbeos] Re: memory beyond 1 gig
- From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 08 Sep 2001 14:27:32 CDT
Yikes! You got me on that one!
I was about to reply to my own message and make a correction. I meant
that you couldn't address more than 4GB RAM with a *single* 32-bit
register. You could always use a pair of registers to access much more.
That would be a segmented memory architecture ala Windows 3.x. I would
hurl vast amounts of puke and head running and screaming towards the
hills if anyone suggests that we use segmented memory in OpenBeOS.
Better to die a thousand deaths.
But I was *completely* unaware of the 36-bit trick. If we can
transparently make use of this --- i.e Pentium Pro users could take
advantage of larger RAM machines, but that users with older machines
aren't penalized -- then fantastic! I'll still stand by the gist of my
earlier comment, but me might be able to pick a higher number than 2GB.
>
>> -----Original Message-----
>> From: openbeos-bounce@xxxxxxxxxxxxx
>> [mailto:openbeos-bounce@xxxxxxxxxxxxx] On Behalf Of Daniel Reinhold
>
>> You cannot (absolutely impossible) address more than 4BG RAM
>> in a 32- bit machine. So that limitation is already built-in.
>
>Incorrect, all ia-32 machines since pentium pro can address 36-bits
(64
>Gb) of ram. You have to use a slightly different set of paging
>structures, but the support is there. You still can only see 4 Gb of
it
>at a time, however, but things such as the file cache and multiple
>address spaces can benefit.
>
>But you will only find the support for that much memory in server
>chipsets. But I suspect that in the next couple of years that will be
>more of an issue. The ia-32 architecture from what I recall will be
>supported for at least the next 4-5 years. But, for example, my athlon
>mobo can support up to 3 gigs of ram. One of these days I'll fill it
>out.
>
>>
>> If we handle the situation correctly in our source code, then
>> it should
>> take only a few minor fixes and a recompile to generate
>> OpenBeOS64. As
>> 64-bit PC's become available on the market, we will have a 64-bit OS
>> ready to install on it.
>
>It's always harder to do then you think, but it would be nice to keep
>that around. I've designed NewOS to be 64-bit if I ever port it to a
>64-bit architecture. I think it'll recompile out of the box for that
>big, but I haven't done it yet. I do have an alpha and an UltraSPARC
>machine, though....
>
>>
>> >
>> >Ok lets kill the 1 gig 'bug' problem. If you use NewOS, you
>> wont have
>> >that limit. There will probably be a 3.5 gig problem, but
>> that is more
>> >of a PC architecture problem than anything else. And that
>> can be fixed
>> >pretty easily by replacing a module in the kernel to turn the
paging
>> >extensions on.
>
>The paging extensions I talk about here is that 36-bit physical
address
>extensions.
>
>> >Now, if you want compatibility enough to run a lot of the
>> beos kernel
>> >modules and drivers you may be out of luck. We can easily enough
>> create
>> >a region in kernel space that maps all of physical ram for these
>> drivers
>> >to use, but then we're back to the same situation, though the NewOS
>> >kernel can probably safely map around 1.5 Gb or so.
>
>I still think this pretty much sums it up. To be a little more in
>detail, the BeOS kernel gets to physical pages by mapping a large
region
>in kernel space that covers all of physical ram. Some drivers use this
>region to, for example, set up IO regions and the VM uses it a lot to
>clear pages befor mapping them in and other such things. The VM in
NewOS
>doesn't have this problem because it has a region in kernel space
where
>pages are mapped in when asked for. See get_physical_page() and
>put_physical_page(). It's a little slower, but you can theoretically
get
>to all 64Gb of physical ram that way.
>
>Travis
>
>
Other related posts:
