Bug 79607 - MTRR setup problem - causes machine to slow down once memory is filled up
Summary: MTRR setup problem - causes machine to slow down once memory is filled up
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 8.0
Hardware: i686 Linux
medium
high
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-12-13 22:43 UTC by Michael Lee Yohe
Modified: 2007-04-18 16:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 15:40:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Michael Lee Yohe 2002-12-13 22:43:15 UTC
Description of problem:
I forget which bug I read Alan Cox's comments on but it was with regards to a
system slowing down to a crawl once it has been up for a good while  (or heavily
used).  For example,

My machine runs very snappy when I first login into Gnome 2.  However, once I
load enough applications to consume all the memory - processes seem to eat more
clock cycles (top shows processes which normally run at 1-5% take 10-25%). 
Windows 2000 did not have this problem.

Alan cited to the reporter of the bug I can't remember that since the Linux
kernel uses the high memory addresses first and then moves down to the lower
memory addresses, it would more than likely be an MTRR related issue.  He also
said that since the Windows kernel uses low memory first to the high memory
addresses, the problem would be less apparent.

Sounds like my system!  He asked for the output of the reporter's /proc/mtrr -
so here's mine:

$ cat /proc/mtrr 
reg00: base=0x00000000 (   0MB), size= 256MB: write-back, count=1
reg01: base=0x10000000 ( 256MB), size= 128MB: write-back, count=1
reg02: base=0x00f00000 (  15MB), size=   1MB: uncachable, count=1
reg03: base=0xd6000000 (3424MB), size=   4MB: write-combining, count=1

The reg00 and reg01 entries look fine since that is the configuration of memory
in the system.  I don't understand what reg02 is and reg03 is particularly strange.

On a completely different system:

$ cat /proc/mtrr 
reg00: base=0x00000000 (   0MB), size= 512MB: write-back, count=1
reg01: base=0x20000000 ( 512MB), size= 256MB: write-back, count=1
reg02: base=0xf0000000 (3840MB), size=  32MB: write-combining, count=2
reg03: base=0xf8000000 (3968MB), size=  64MB: write-combining, count=1

The reg02 and reg03 definitely look strange but particularly it is missing the
uncacheable entry that exists on the problem machine.  This machine has no speed
related issues.

How reproducible:
Always

Additional info:

$ rpm -q kernel
kernel-2.4.18-18.8.0
kernel-2.4.18-14
kernel-2.4.18-14
kernel-2.4.18-17.8.0

Comment 1 Bugzilla owner 2004-09-30 15:40:17 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/



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