Re: Terrible IO performance when using 4GB of RAM on a 32 bit machine
From: Robert Hancock
Date: Fri Jun 22 2007 - 10:38:35 EST
Peter Rabbitson wrote:
Robert Hancock wrote:
Peter Rabbitson wrote:
H. Peter Anvin wrote:
What does /proc/mtrr look like in the two cases?
Identical for mem=3900 and without it.
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 512MB: write-back, count=1
reg03: base=0xe0000000 (3584MB), size= 256MB: write-back, count=1
reg04: base=0xf0000000 (3840MB), size= 128MB: write-back, count=1
reg05: base=0xf8000000 (3968MB), size= 32MB: write-back, count=1
Looks like another case of bad MTRRs on an Intel motherboard? The BIOS
is marking only memory up to 4000MB as cacheable, but the actual
memory extends up to about 4031MB. Therefore anything that accesses
the top 31MB of memory will run very slow.
Ah, it all makes sense now. In this case I assume mem=4000 is perfectly
safe and usable for the time being. In the beginning I tried with
mem=4g, which obviously did not work. If anyone is interested in adding
an exception/workaround for this particular motherboard, I'd be happy to
help with testing. I have added more information about the system:
current kernel config [1], output of `lspci -vv`[2], dmesg with
mem=4000[3].
Thank you!
Peter
There was a patch floating around recently to detect the case where the
MTRRs don't map all of RAM as write-back, automatically cap the memory
used by the kernel to what is mapped and print some loud warnings..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/