Bug 194048 - Copy preformance dismal with memory remapping enabled
Copy preformance dismal with memory remapping enabled
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-05 08:19 EDT by Wayne Buttles
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-16 13:07:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Wayne Buttles 2006-06-05 08:19:50 EDT
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)
4G ram
LSI MegaRAID 150-6 SATA 64/66 PCI RAID Controller w/ 64MB in RAID 1.


How reproducible:

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
3. wait
  
Actual results:

2 - 10 minutes at least to copy the file.


Expected results:

1 - 1.5 minutes max

Additional info:

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.
Comment 1 Rik van Riel 2006-06-20 16:35:06 EDT
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" ?
Comment 2 Wayne Buttles 2006-06-21 07:33:54 EDT
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
Comment 5 Rik van Riel 2006-08-16 13:07:42 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.