[CentOS] Re: Offtopic Posts [was Re: [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing]

Maciej Żenczykowski maze at cela.pl
Wed Jun 29 07:56:09 UTC 2005


> I'm also going through the kernel's VM right now.
> There are no less than 5 major models to x86/x86-64.
> And it _does_ require you to use a "BIOS hack" that is COMPLETELY
> INCOMPATIBLE with PAE36 OSes.
>
>> Ironic that I say that while I agree with Bryan so
>> much on 3ware and board design, uch?

I have a question here, is the performance issue to deal with PAE36 to do 
with the way memory is organized?  Note, my knowledge of >32bit extensions 
is very limited - so I'm just guessing about how it could be...

ie. in normal Intel PAE36 you select and page in 8 512MB linear areas 
(from a total max of 36bit / 64GB physical RAM) into the normal 32bit 
address space, and these are the 4GB you can access, if you want to access 
some other memory then you have to replace a full 512MB block with a 
different 512MB block.  This makes the top 4 (for 36bit) or 8 (for 40bit) 
address bus lines derived from the top 3 bits of a 32bit address by some 
very small nearly external to the CPU lookup table (ie. it's tacked on 
almost as an afterthought?)

while in this extended athlon mode, due to the processor being >32bit 
internally and not just externally you can somehow page in any 4KB page 
from anywhere in the 36bits of address space (or even 40bit???) into any 
spot into physical memory.  So you still have a 32bit address space, but 
it's not limited to only accessing 8 512MB blocks, instead it accesses any 
4KB pages from the whole of physical memory in any order?

Is that it?  Because if it is this would make it obvious why the second is 
'truely' 36 or 40bit while the first is a hack :)
[although the second would be considered the hack since the first was 
first...]

Cheers,
MaZe.



More information about the CentOS mailing list