What is "dual-channel DDR"?

[Lennart Sorensen]

On Wed, Mar 16, 2005 at 04:09:47PM -0500, Andrew Hammond wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm sorry, but PAE works exactly as Chris described below. If anything,
> he's too gentle describing the cost as "pretty appreciable". Consider
> that for architectures which support this egregious hack, all the IO has
> to pass over the Front Side Bus. The FSB is a bottleneck on modern
> single processor systems and only gets worse with multiple processors.
> 
> On a Xeon system (EM64T or otherwise) an inbound IO now follows this
> pattern:
> 1) northbridge -> FSB -> memory
> 2) context switch triggers page switch: memory -> FSB -> PAE controller
> - -> FSB -> memory
> 3) memory -> FSB -> CPU (kernel)
> 4) CPU -> FSB -> memory
> 5) memory -> FSB -> PAE -> FSB -> memory
> 5) memory -> FSB -> CPU (application)
> 
> So, data in the bounce buffer (since Chris has us using BSD terminology)
> goes through the FSB a total of 8 times. And this is assuming that
> there's no cache stupidity due to processes migrating between CPUs.
> EM64T makes the Xeon a 64bit chip in the same way that putting racing
> strips and a big ass wing on the back of a '89 Pinto makes it a race car.
> 
> PAE is NOT supported on Opterons. The hardware to do paging just isn't
> there. Running a 32bit OS on an Opteron with >4G of memory would be
> foolish since the extra memory is inaccessible. There are some merits to
> running 32bit code on an Opteron, which is what I assume you're talking
> about here. Both SuSE and Redhat support the lib / lib64 convention.
> However pointer storage space is, for most programs, not worth
> considering. The real win (such as it is) from running in 32bit is that
> the binaries are about 10% smaller on average and hence load from disk a
> little quicker and consume a little less memory IO in operation.

Hmm here is the output on Linux from some dual Opteron system:
processor: 0
vendor_id: AuthenticAMD
cpu family: 15
model: 5
model name: AMD Opteron(tm) Processor 242
stepping: 1
cpu MHz: 1595.046
cache size: 1024 KB
fpu: yes
fpu_exception: yes
cpuid level: 1
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips: 3178.49
TLB size: 1088 4K pages
clflush size: 64
address sizes: 40 bits physical, 48 bits virtual
power management: ts ttp

processor: 1
vendor_id: AuthenticAMD
cpu family: 15
model: 5
model name: AMD Opteron(tm) Processor 242
stepping: 1
cpu MHz: 1595.046
cache size: 1024 KB
fpu: yes
fpu_exception: yes
cpuid level: 1
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips: 3185.04
TLB size: 1088 4K pages
clflush size: 64
address sizes: 40 bits physical, 48 bits virtual
power management: ts ttp

I wonder what the flags pae, pse and pse36 mean.

It would have been insane for AMD not to support intel's 64GB memory
access method since Windows wasn't going 64bit anytime soon, and being
able to use more than 4GB ram on such a system would be essential.  It
is possible that they actually avoid the whole mess behind the scenes
when doing the actual access, but to the software it has to look just
like an intel using pse36 and pae to access memory beyond 4GB.  That
would be clever use of the hardware's real abilities after all.

Lennart Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml