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

[alex at milivojevic.org]

Quoting Peter Arremann <loony at loonybin.org>:

> On Saturday 25 June 2005 16:18, Bryan J. Smith wrote:
>> Dude, you're totally mis-appropriating simple board layout
>> specifications to how the logic of the bus works. That's why I'm not
>> even going to discuss this any longer.
> Then enlighten me - if I have 40 address bits - transmit only the higher 37
> since I don't need the lower end. Timing schemas show only one Input hold
> time per address transfer for all available pins - how can that be a 32bit
> bus? (ftp://download.intel.com/design/Xeon/datashts/30675401.pdf)
> And, if timing diagrams, pinouts and so on lie about the size of the 
> bus, what
> is actually going on, then I guess its true - Intel uses voodoo magic to
> design their chips and they added extra address pin, never ever use them and
> the MCH figures out the missing address bits by some more ocult means
> (http://www.amazon.com/exec/obidos/ASIN/B00001ZWV7/104-8776547-8655150)

Well, this is how I interpreted Bryan's emails.  He'll probably correct me if
I'm wrong (yeah, I have EE, but haven't done much EE work since I 
graduated, it
just happened to be mostly "software" things for me, so I'm rather rusty here
:-(

I don't think Bryan is talking about "external" width of the address bus, how
many lines you see printed on the motherboard.  He's talking how the 
things are
organized internally, and about the way the bus logic works.  That 
would be what
theoretically implementations might use, not what some specific implementation
is limiting itself to.

Sorry for mixing software and hardware from now on, just trying to make Peter
see where his misconception is (the best way I can, which might not be 
good way
at all).  The programming model for 32-bit userland applications is obviusly
limited to 32 bits -- the sizeof(void *) will tell you that.  So single 
process
can see only 32-bit logical linear address space.  On the other hand, 
processor
(the hardware) doesn't need to have such limits, if it's internal organization
is wider.  So, AMD (processor) is able to see 40-bit linear physical address
space as one single big chunk of memory.  32-bit applications will have their
32-bit *logical* address space mapped into this 40-bit linear *physical*
address space of processor.  I don't know if programming model of "32-bit" AMD
processors allows you to have wider-then-32-bit pointers (even if it did, you
would have to have compiler that can generate such code, gcc can't do it for
sure).  Obviously, the kernel needs to know how to manage things in this wider
physical address space, the reason why you need patched Linux kernel to take
advantage of it.  Intel (the processor) on the other hand, is able to
physically address only 32-bit address space.  Anything wider than that, it
needs to page.  Dealing with paging will obviosly be additional work for OS,
hence lower performance.

So while both processors will have more that 32 address lines on the packaging
(and printed on motherboard) minus couple of lowest one (that are not needed)
as you can see in various specifications that you queted, that doesn't mean
processor's core actually sees all that address space.

How else to try explaining this...  Hm... Remeber Intel 8086?  It could 
address
only 16-bit address space, but it had more than 16 address lines on the
packaging.  It used segmenting (hopefully the right term) to see
wider-than-16-bit address space.  Now try to make analogy with what was
discussed so far ;-)


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.