[Beowulf] Tyan mobo and /proc/mtrr

[Mark Hahn]

> How do mtrr settings affect performance?  

they, along with per-page attributes, determine how the CPU
treats the cachability of an address.

> Anybody know what /proc/mtrr "should" say on various Tyan
> mobos?

why do you think there's a problem?

> Three types of Tyan systems here, this is what /proc/mtrr has for each:
> 
> S2468UGN    2.6.8.1  (in MDK10.0)
> reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
> reg01: base=0xf5000000 (3920MB), size=   1MB: write-combining, count=1
> S2466N      2.6.8.1  (in MDK10.0)
> reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
> reg01: base=0xf5000000 (3920MB), size=   1MB: write-combining, count=1
> S2466N      2.4.18-10 (in RH7.3)
> reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
> 
> The first line describes the total memory in the system.
> The second line, if present, corresponds to a  setting from
> the ATI RAGE XL graphics card.  The ones running the older OS
> don't even do that.

mtrr values are supposed to be set by the bios; the OS certainly
can change them, but doesn't have to.

I forget for sure, but suspect that in the absence of an mtrr,
the mem-mapped video area on the third machine would default to 
write-through or -combining.

of course, all this stuff was terribly novel back in the dark ages 
of RH 7.x.  it wouldn't be shocking if RH7.3 got it wrong...

> Should there be additional mtrr settings, and if so, why?

the main thing is simply to have all real ram in write-back;
mtrr's for video can make a difference, but often not as much 
as you might expect, because the CPU does a certain amount of 
write coalescing before data even gets to the cache.

> Note, lspci reports this for the RAGE XL graphics (on all):
> 
>         Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
>         I/O ports at 1000 [size=256]
>         Memory at f4000000 (32-bit, non-prefetchable) [size=4K]
> 
> Unclear to me why only 1M of the reported 16M is mapped (apparently)
> by the mtrr.  Possibly  this relates to these messages:
> 
>   /var/log/messages:Oct 20 12:44:59 safserver kernel: mtrr:\
>   0xf5000000,0x400000 overlaps existing 0xf5000000,0x100000

IIRC, this is perfectly legal - in fact, the correct way to define
a 3MB region is to define a 4MB region and an overlapping 1MB region.

> On the other hand, the graphics aren't really used
> on the S2466N compute nodes.

so ignore them.  they can't possibly matter...

> Graphics are used more on the
> S2468UGN server. Beats me where one would change this value
> though.

there's an mtrr doc on kernel/Documentation which is all you need,
*if* you actually need to change anything.  it seems like X started 
fixing mtrr's several years ago using this interface (/proc/mtrr).

I would guess that mtrr's on the framebuffer were less relevant 
for a number of years (using a video card's hw acceleration 
obviates the need for the host to directly manipulate the pixels).
this may be less true now with some of the newfangled client-side
rendering, etc.