[openbeos] Re: memory beyond 1 gig
- From: "Michael Phipps" <mphipps1@xxxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 07 Sep 2001 21:58:50 -0400
Maybe you are not aware of to whom you speak.
JBQ was an employee of Be.
An excellent engineer and a person who has a very advanced
knowledge of kernel engineering and issues.
>> The memory bug that keeps BeOS from using more than 1 gig
>
>It's not a bug.
It is a huge bug. I am learning what caused this right now, as I look at the
kernel issues. And it is a bug. No question. Now - Be knew about it and probably
didn't care because up until the last year or so memory was not cheap. A
gig was beyond the realm of most people.
>Physical memory limitations in BeOS have nothing to do with memory model
>but with address space management policies.
That is not true. Very simply, Be chose a physical memory model that has
limitations.
> Address space != Physical Memory Size
>
>
>> *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.
>> Depends on how big everyone thinks things will get in 2 years.
>
>This full paragraph makes me think that you don't fully understand VM
>management.
Trust me - you are wrong here.
>> 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.
>
>That's the wrong policy... you must make sure that all your scalar types
>are properly typedef'ed instead of using shorts, ints, longs all over
>the place. Forcing them to be 64 bits imposes unrequired overhead.
>Properly typedefing allows you to move to another architecture without
>putting unrequired overhead.
What he is saying is that anything that would need to be larger on a different
machine is 64 bit. Not that every number you ever use is 64 bit.
>manuel, [ back to lurk mode ]
>
>> (ie: 64 bit MPU)
>>
>> Peter
>>
>
>
>
Other related posts:
