Red Hat Bugzilla – Bug 194048
Copy preformance dismal with memory remapping enabled
Last modified: 2007-11-30 17:07:25 EST
Description of problem:
A copy that should take 1 minute can take up to 10 with very high machine
sluggishness if the "memory remap feature" is enabled in bios.
Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
LSI MegaRAID 150-6 SATA 64/66 PCI RAID Controller w/ 64MB in RAID 1.
Just copy a gig file and wait.
Steps to Reproduce:
1. Take a gateway 9415 with 4G ram, megaraid, memory remap on and RHES4
2. copy a 1 gig file
2 - 10 minutes at least to copy the file.
1 - 1.5 minutes max
Is this a misconfiguration on my part of some other setting or component or
crappy hardware? I'd like to reclaim the .5 gig lost to the pci space but not
at the cost of performance.
Looks like the top .5 gig is not cacheable when it is remapped above 4GB. Could
you please give us the output of "cat /proc/mtrr" ?
All I can give is the "memory remap feature" OFF version since the machine is
now in production. I'm guessing that isn't helpful, but I couldn't wait.
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
If the BIOS marks something as not cacheable, the kernel should probably not try
to make that memory cacheable anyway - that could break on systems where the
memory is device memory, which could end up corrupting data if it is accessed in
a cacheable way.
The problem you are running into should either be fixed on the BIOS side, by
having the remapping code in the BIOS set up the e820 table in a way that marks
the high RAM as cacheable, or maybe worked around by disabling memory remapping,
or manually making the memory cacheable through /proc/mtrr.
Trying to work around this issue in the default RHEL kernel could be dangerous
for other users, so this is not something we will attempt.