On Feb 25, 2005, at 8:20 PM, Trent Shipley wrote:

> On Friday 2005-02-25 16:41, Joseph Sinclair wrote:
>> BTW, if you're running a 32-bit CPU (or 32-bit kernel), don't allocate
>> more than 2G, the system generally won't be able to address it.  If
>> you're running a 64-bit CPU(with a 64-bit kernel), then allocate as 
>> much
>> as you need, since the system'll be able to address whatever you
>> allocate up to around 8 petabytes.
>
> Why would you write the 32 bit kernel to address virtual memory with a 
> signed
> integer instead of an unsigned integer, especially when (as I recall) 
> the
> current Linux kernel can address 4Gig of memory?
>
> Out of curiosity, could you have 4 Gig of main memory and then use up 
> to 2|4
> *RAM memory as swap by telling the system to treat it as a virtual 
> drive?  If
> it can be done, what result should one expect (assuming a memory 
> intensive
> application)?

Because it's not quite an unsigned integer. Memory addresses cannot "go 
negative" -- the closest we have to that on the intel platform is the 
relative jmp instruction, which can only go (last I remember) +/- 127 
instructions. The problem is that you're segmenting the 32 bits into an 
offset and a "memory selector".

Even if you're running in a flat memory space (like several operating 
systems, games, and demos do) you _still_ have at least one bit of that 
32 bit address that is chopped off for the selector (in technical 
terms, the selector refers to the entire memory space). So, you're 
limited to the 4GB address space, unfortunately.

Extensions to this were written by Intel to handle >4GB, IIRC. I think 
they refer to it as PAE -- some kind of memory paging extension.

Just a quick non-technical rundown from an ex-kernel hacker -- HTH. =o)

--
June Tate * http://www.theonelab.com * june@theonelab.com