fc1_x86_64 preview on tyan thunder k8w (S2885ANRF REV .03)

Philip Pokorny ppokorny at penguincomputing.com
Sat Dec 13 04:53:17 UTC 2003


 > Message: 23 Date: Fri, 12 Dec 2003 08:01:42 -0500 (EST)
 > From: Joshua Baker-LePain <jlb17 at duke.edu>
 > To: fedora-test-list at redhat.com
 > Subject: Re: fc1_x86_64 preview on tyan thunder k8w (S2885ANRF REV .03)
 >
 > Thomas Dodd wrote
 >>> Thats different. You end up needing some mappings for kernel and
 >>> user space to be efficient when dealing with user mappings. Whether
 >>> you can get your .5Gb back depends if the chipset can remap it
 >>> higher up in memory
 >>> so that the 3.5-4Gb RAM masked by PCI is remapped at the top of
 >>> memory.
 >>
 >> Know which ones, if any, currently can? AMD, Nvidia, or VIA?
 >> Why would they release a chip that couldn't?

I've only seen this feature on the Intel Plumas chipsets (E75xx)

 > In my (limited) experience, I've only "lost" significant chunks of
 > memory on Tyan boards. Here are the results of 'free' on two systems
 > with 4GB of RAM installed:
 >
>              total
> Mem:       3688032
> 
>              total
> Mem:       4012172
> 
 > The first system is dual Athlon MPs on a Tyan S2466.  The second is
 > dual Xeons on a Supermicro P4DPE.

This isn't a Tyan vs SuperMicro issue.  You've got two different 
chipsets here.  The Tyan S2720 (equivalent to the P4DPE) will give you 
the same amount of available RAM as the P4DPE because it has the same 
E7500 chipset.

The S2466 is limited by the AMD760 chipset.  The memory controller only 
has 32-bit addressing so when you install 4G of RAM, you loose whatever 
is needed for your PCI peripherals.  With only 32-bits, there is no 
place to map the memory to.

This is part of the answer to why someone would release a chipset that 
can't remap memory.  The Athlon MP CPU's don't have PAE extended 
addressing mode support, so they can only address 4G of total address 
space so there is no reason to implement memory remapping.

Another factor here is that the S2466 is a workstation board and you 
might have had a video card with 64MB or 128MB of memory on it 
installed.  Due to the way PCI addresses are assigned, a 128MB video 
card effectively consumes a little more than 256MB of address space. 
The P4DPE is a server board and so you only had a 4MB or 8MB video 
buffer for the on-board ATI Rage graphics controller.  That only uses 
8MB or 16MB of address space.  Even without memory remaping, the P4DPE 
is going to win.

By the way, if you have a hot-swap capable system, you can loose even 
more RAM because empty PCI slots have to have memory space reserved for 
them in case a PCI card is installed after the system POST's.  The 
default is generally to allocate 128 or 256MB of memory space to *EACH* 
hotswap slot.  Three or four hot-swap slots eat up almost a 1G of memory!

 > For good measure, here's free from
 > a dual Opteron system with 8GB installed:
 >
>              total
> Mem:       8070688 
> 
> That's the Arima/Rioworks HDAMA motherboard.  Given my past experiences 
> with Tyan and AMD chipsets (read: S2460 *shudder*), I specifically 
> requested that my vendor *not* use the Tyan MB in my Opteron systems.

I've had good success with the Tyan motherboards. All the way from dual 
PIII, P4 Xeon and on to Opteron.

The Arima HDAMA is also nice.  But on the very early HDAMA BIOS's you 
could loose as much as 1G in a 4G config because the Phoenix BIOS was 
sloppy.

But again, it's not a motherboard manufacturer issue. You loose the 
memory under your PCI space with the Opteron's same as the Athlon no 
matter whose motherboard you use.  The Opteron does have PAE mode 
support and plenty of address bits, but the memory controller on the CPU 
apparently doesn't have a way to remap that memory.  Being as the memory 
controller is actually on the CPU and must be accessed cache-coherently 
in a multi-CPU board, adding memory remapping to get back 256MB or 512MB 
out of 4096MB (or more) must not have been worth it.

:v)

-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com





More information about the fedora-test-list mailing list