答复: Large mmio resources and 4G+ of RAM...

[YhLu]

Then in LinuxBIOS We can access the memory in 64 bit mode directly. And
maybe do the memory check and test. Memory problem is a big problem in
system integration.

Some time 8 ways system, every cpu has 4 dimm, total memay will be
4G*4*8=128G.

Regards

YH

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 
发送时间: 2004年6月1日 10:41
收件人: YhLu
抄送: Stefan Reinauer; LinuxBIOS
主题: Re: Large mmio resources and 4G+ of RAM...

YhLu  writes:
> Eric,
>
> There is something called Memory lifting or memory remapping for Opteron.
> For example if 2G for one Opteron and two ways system.
>
> Then the CPU 0 will use [0,2G), and CPU 1 will use [4G, 6G).
>
> If the RAM for CPU is above 4G, then We must lost 1/2G for MMIO range, the
> reason is Opteron only has two reg for RAM LOW and HIGH limit. And there

is
> no other regs to record the memory hole. But it seems Intel CPU has more
> regs to remember the memory hole.

Memory lifting is nice.  And in certain specific instances it is useful.
On the Opteron it is possible to move either Memory controllers, or
DIMMS.  At 4G per memory controller it does not work to move memory
controllers, at paired singled sided 2G DIMMS you can't move DIMMS.

So the other solution is to move the large MMIO resources.  Moving the
MMIO resources has the advantage that
A) It is simple.
B) It works in all circumstances (baring issues with bridges)
C) Is needed if you have many large MMIO regions.
D) It works on all CPUs.
E) A 32bit kernel could support it with highmem type tricks...

So I think I would rather pursue moving the large MMIO resources
first.  The limited utility of memory lifting doesn't inspire me
to worry about it.

Although the few circumstances the Opteron memory lifting applies to
may be the only cases people really care about loosing that much
memory.

Eric

YhLu  writes:
> Then in LinuxBIOS We can access the memory in 64 bit mode directly.

We already do, on the Opteron.
> And
> maybe do the memory check and test. Memory problem is a big problem in
> system integration.

Unless you spend days at it you cannot do a good memory check/test.
I don't want to wait days while my system boots.  A cursory check
That verifies the memory doesn't totally suck is ok.  But I don't
want to see anything that conveys the impression that LinuxBIOS
has actually checked the memory.

The best tests I know of involve monitoring for ECC errors while
the system is being stressed.
> Some time 8 ways system, every cpu has 4 dimm, total memay will be
> 4G*4*8=128G.

I'm not certain you can plug that many 4G dimms into an Opteron.  At the
very least they are a challenge to come by...

As for setting up and debugging memory the first system with LinuxBIOS
on the Opteron Lighting had 6TB of ram...

Eric

[ron minnich]

On 1 Jun 2004, Eric W. Biederman wrote:
> Unless you spend days at it you cannot do a good memory check/test. I
> don't want to wait days while my system boots.  A cursory check That
> verifies the memory doesn't totally suck is ok.  But I don't want to see
> anything that conveys the impression that LinuxBIOS has actually checked
> the memory.

yes, bios memory tests are completely useless, have only found a memory 
error for me when the DIMM was half out of its socket!

ron