Re: Not MTRR !? was: ISSUE: very slow (factor 100) 4-way 16GByte server, with 2.4.2
Rik van Riel <[EMAIL PROTECTED]> writes: > On Wed, 28 Mar 2001, Robert Suetterlin wrote: > > reg00: base=0xfb00 (4016MB), size= 16MB: uncachable, count=1 > > reg01: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1 > > reg02: base=0x ( 0MB), size=8192MB: write-back, count=1 > > reg03: base=0x2 (8192MB), size=4096MB: write-back, count=1 > > reg04: base=0x3 (12288MB), size=2048MB: write-back, count=1 > > reg05: base=0x38000 (14336MB), size=1024MB: write-back, count=1 > > reg06: base=0x3c000 (15360MB), size= 512MB: write-back, count=1 > > reg07: base=0x3e000 (15872MB), size= 256MB: write-back, count=1 >-- + > 15.75 GB > > It looks like the last 256MB isn't cached (well, it doesn't > have an MTRR at all) and Linux starts loading programs from > the top of memory ... It looks like the BIOS ran out of MTRRs. I suspect this is one of the reasons that Intel changed the PPro spec to allow overlapping MTRRs in some cases, with uncached taking precedence. The following sequence of /proc/mtrr commands should give the same uncachable range with all memory write-back cached: # cat >/proc/mtrr disable=2 disable=3 disable=4 disable=5 disable=6 disable=7 base=0 size=0x4 type=write-back base=0x4 size=0x400 type=write-back base=0x40400 size=0x100 type=write-back ^D (I think all those zeros are correct. 0x4 == 16GB, 0x400 == 64MB, 0x100 == 16MB) It's probably also worth seeing if a BIOS update is available. Dave Wragg - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Not MTRR !? was: ISSUE: very slow (factor 100) 4-way 16GByte server, with 2.4.2
Hello everyone. As far as I can see almost all memory is set write-back. The memory at the far end belongs to some hardware, see /proc/iomem below. Are there any other suggestions why our machine is so slow, or perhaps 'write-back' is the reason??? If You need more info, please tell me, I will gladly provide it. Or if I can make any tests / benchmarks, ask for it. Sincerely, Robert S. /proc/mtrr reg00: base=0xfb00 (4016MB), size= 16MB: uncachable, count=1 reg01: base=0xfc00 (4032MB), size= 64MB: uncachable, count=1 reg02: base=0x ( 0MB), size=8192MB: write-back, count=1 reg03: base=0x2 (8192MB), size=4096MB: write-back, count=1 reg04: base=0x3 (12288MB), size=2048MB: write-back, count=1 reg05: base=0x38000 (14336MB), size=1024MB: write-back, count=1 reg06: base=0x3c000 (15360MB), size= 512MB: write-back, count=1 reg07: base=0x3e000 (15872MB), size= 256MB: write-back, count=1 /proc/iomem -0009e3ff : System RAM 0009e400-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000c8000-000c8fff : Extension ROM 000c9000-000cdbff : Extension ROM 000f-000f : System ROM 0010-fafe : System RAM 0010-00246b38 : Kernel code 00246b39-002a8f9f : Kernel data faff-fafffbff : ACPI Tables fafffc00-faff : ACPI Non-volatile Storage fb00-fbff : ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC] fc00-fc0f : Intel Corporation 82557 [Ethernet Pro 100] fc10-fc100fff : Adaptec AIC-7880U fc101000-fc101fff : Intel Corporation 82557 [Ethernet Pro 100] fc102000-fc102fff : ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC] fc103000-fc103fff : PCI device 1166:0220 (ServerWorks) fc40-fc400fff : Adaptec 7899P fc401000-fc401fff : Adaptec 7899P (#2) fc402000-fc4020ff : Compaq Computer Corporation PCI Hotplug Controller fc80-fc81 : Intel Corporation 82542 Gigabit Ethernet Adapter fc82-fc8200ff : Compaq Computer Corporation PCI Hotplug Controller (#2) fcc0-fcc03fff : PCI device 1119:016d (ICP Vortex Computersysteme GmbH) fec0-fec0 : reserved fee0-fee00fff : reserved ffc0- : reserved - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
