MTRR survey: better X performance on systems with 3G or more RAM

D. Hugh Redelmeier hugh at mimosa.com
Mon Apr 13 03:58:38 UTC 2009


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: 




More information about the fedora-list mailing list