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
(text/plain)
