[openbeos] Re: memory beyond 1 gig
- From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sat, 08 Sep 2001 12:47:05 CDT
No Michael, it's not a bug. It's a design limitation. All designs have
them. Our design will too.
I'm quite weary of people using the word "bug" to describe any
consequence they don't like. It waters down the meaning to the point
that it's no longer useful. A true bug is when the software fails to
meets the expectations for the environment it was intended for.
The main reason I dislike people using the term "bug" so generally is
that it puts an unspoken pressure on programmers to figure out all
future contingencies that will occur with their software. That is
absolutely impossible to do. The desire to try, however, wastes a lot
of time and generally produces code bloat.
Jeez, we haven't even hit this design limitation yet (how many users
have 1 gig+ RAM at the moment?) and it's already called a bug. Don't
get me wrong, this memory limitation is a problem and it will start
affecting users in the next year or two. It does need to be addressed
in the design of OpenBeOS.
The real lesson here is that every design decision made has
consequences. Document those decisions! Inevitably, one of more of them
will turn out to prove limiting and will have to be re-engineered.
>
>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:
