MTRRs are still not handled well in X. I suspect this shows up in a
lot of machines with 3G or more of memory. I'd like to know how
common this is.
I'd like affected people to answer my informal survey. In return, I
will suggest how you can speed up your system.
MTRRs control how memory is cached. The BIOS sets up the address
range for video cards to "uncached". X video drivers try to change
this to "write-combining". The way that BIOSes set up MTRRs on
systems with a lot of memory often prevents X doing this. The result
is a performance loss.
How can you tell if this affects your system?
- if you are not running X, you are not affected: you may stop reading
here.
- if your system has less than 3G of RAM, it probably isn't
affected: you may stop reading here.
- if your X video driver is the nVidia proprietary driver, it isn't
affected (nVidia uses the PAT hardware feature instead of MTRRs):
you may stop reading here.
[If you get here without an answer, I'd like to hear about your
situation.]
- if your system is using the proprietary ATI driver, I don't know. It may
use PAT. I'd like to know.
- What does this command report?
grep write-combining /proc/mtrr
If no lines are shown, your system is probably affected.
If you are affected, what can you do?
- run glxgears from a shell for half a minute to get a somewhat
meaningless performance reading before any improvement. Record
these somewhere.
- if your kernel is current, try the kernel parameter
enable_mtrr_cleanup. You put it in /boot/grub/grub.conf on the
appropriate "kernel" line (perhaps after "quiet"). Of course you
have to reboot for this to take effect.
- Instead, you could run my mtrr-uncover program.
ftp://ftp.cs.utoronto.ca/pub/hugh/mtrr-uncover-2008oct01.tgz
That has worked in cases where enable_mtrr_cleanup has not worked
or where it is unavailable. Don't forget the --execute flag.
You must restart X for the change to affect X performance
(control-alt-backspace will restart X).
The effect will go away upon reboot so you might want to put it
in /etc/rc.local to run it at each boot (only do this
if mtrr-uncover worked for your system).
- after either of those:
+ do the grep again: it should print a line
+ run glxgears again to see if anything changed.
=== Example system 1: Hugh's Lenovo notebook
Computer brand and model: Lenovo Thinkpad x61t
video controller: intel GMA X3100
X video driver: intel
RAM: 4G
distro: Ubuntu 8.10 for AMD64
MTRR problem: yes
Fix: mtrr-uncover
glxgears performance change: 350 FPS => 630 FPS
=== Example System 2: Paul's Lenovo notebook
Computer brand and model: Lenovo Thinkpad x61t
video controller: intel GMA X3100
X video driver: intel
RAM: 4G
distro: Fedora 9 x86_64
MTRR problem: yes
Fix: mtrr-uncover (enable mtrr_cleanup failed)
glxgears performance change: 140 FPS => 650 FPS
Interestingly, the enable_mtrr_cleanup approach did not work -- it
said (kernel log):
mtrr_cleanup: can not find optimal value
please specify mtrr_gran_size/mtrr_chunk_size
Since the documentation for these flags is unclear to us
we didn't know how to set them appropriately.
=== Example System 3: Hugh's desktop
Computer brand and model: HP Pavilion A6245n (Intel Core 2 Quad 6600)
video controller: Asus EAH 3650 Silent Magic Video card
X video driver: open source "ati" driver
RAM: 6G
distro: Fedora 10 x86_64
MTRR problem: yes
Fix: mtrr-uncover and enable_mtrr_cleanup both work
glxgears performance change: 220 FPS => 400 FPS
Note: the glxgears performance appears to be affected by what should
be irrelevant factors. It looks as if having Firefox running with a
lot of windows open reduces the reading. So glxgears is not a great
test.
==============================
What I'd like to know about your system:
Computer brand and model (or motherboard info):
video controller:
X video driver:
RAM:
distro:
MTRR problem:
Fix:
glxgears performance change:
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
