The last few months I recognized that my GNOME environment feels slower than it felt before. This is only related to my laptop which I don't use very often, so I didn't really focused to find a solution for this problem. Now I read a thread about the MTRR and PAT stuff. My Processor doesn't support PAT, so MTRR stuff is used for partitioning my systems address range. Also I read X will make an MTRR entry for the address range of my graphics card and mark it as "write-combining" to make graphics related things load faster. This actually is not happening. In my X logs no MTRR related line can be found. Therefore X doesn't care about my MTRR entries at all. My question is how I can make X to set the right MTRR entry for my graphics cards address range? Can I force it to do so in any way? Approximately 2 years ago my Desktop environment in 2D mode felt really faster than it is today, so I think it's X settings related or something is missing in my kernel config... Hope you guys can help me out with this so I can use the full power of my good old Sony laptop. Reproducible: Always Steps to Reproduce: 1. Boot in text-mode. /proc/mtrr looks like: reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back 2. Boot in graphics mode (starting /etc/init.d/xdm) /proc/mtrr looks like: reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back 3. No mtrr related log output is written to log Actual Results: /proc/mtrr looks like reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back Expected Results: X server should make an entry in /proc/mtrr which sets the address range of my graphics card to mode "write-combining"
Created attachment 245576 [details] xorg.conf
Created attachment 245577 [details] X log
Portage 2.1.8.3 (default/linux/x86/10.0/desktop/gnome, gcc-4.4.3, glibc-2.11.2-r0, 2.6.35-gentoo-r4 i686) ================================================================= System uname: Linux-2.6.35-gentoo-r4-i686-Intel-R-_Pentium-R-_M_processor_2.00GHz-with-gentoo-1.12.13 Timestamp of tree: Sun, 29 Aug 2010 11:15:03 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] app-shells/bash: 4.0_p37 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.3-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=pentium-m -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/ http://ftp-stud.hs-esslingen.de/pub/Mirrors/gentoo/ http://mirror.switch.ch/ftp/mirror/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/ " LANG="de_DE.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa apm bash-completion berkdb bluetooth branding bzip2 cairo cdda cdr cli consolekit cracklib crypt css cups cxx dbus dri dts dvd dvdr eds encode evo exif fam ffmpeg firefox flac fontconfig fortran ftp gdbm gdu gif gnome gnome-keyring gphoto2 gpm gstreamer gtk hal hddtemp iconv icq ieee1394 jpeg lcms ldap libnotify lm_sensors mad matroska mikmod mmx mng modules mp3 mp4 mpeg mplayer mudflap nautilus ncurses nls nptl nptlonly nvidia ogg opengl openmp pam pango pcre pdf perl png policykit ppds pppd python qt3support readline reflection samba scanner sdl session spell spl sse sse2 ssl startup-notification svg sysfs tcpd tiff truetype unicode usb vorbis win32codecs x264 x86 xcb xinerama xml xorg xulrunner xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 245578 [details] Actual kernel config
Doug, this looks like a driver bug to me. Feel free to reassign it back if I get it wrong. :) Thanks
This isn't an issue. You really only need write back or write combining, and in fact write back is more efficient than write combining. Write combining basically says that your memory is write through (e.g. must be written back to memory right away) but instead of listening to each and every write its able to combine those writes. Write back allows the write to happen to the CPU cache and just mark the cache dirty and the update will be sunk back to memory at a later time. For more details on PAT & MTRR, see the Intel Developers Manuals @ http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html
(In reply to comment #6) > This isn't an issue. You really only need write back or write combining, and in > fact write back is more efficient than write combining. > > Write combining basically says that your memory is write through (e.g. must be > written back to memory right away) but instead of listening to each and every > write its able to combine those writes. > > Write back allows the write to happen to the CPU cache and just mark the cache > dirty and the update will be sunk back to memory at a later time. > > For more details on PAT & MTRR, see the Intel Developers Manuals @ > http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html I take it back and should say that write combining is actually a super set on write back, so you are correct you will get improved performance there.
(In reply to comment #7) > (In reply to comment #6) > > This isn't an issue. You really only need write back or write combining, and in > > fact write back is more efficient than write combining. > > > > Write combining basically says that your memory is write through (e.g. must be > > written back to memory right away) but instead of listening to each and every > > write its able to combine those writes. > > > > Write back allows the write to happen to the CPU cache and just mark the cache > > dirty and the update will be sunk back to memory at a later time. > > > > For more details on PAT & MTRR, see the Intel Developers Manuals @ > > http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html > > I take it back and should say that write combining is actually a super set on > write back, so you are correct you will get improved performance there. Ok, thanks for the info. Do you have any idea how I could get a write-combining MTRR entry? Do you need more information about my system? Glad to hear from you!
I keep meaning to come back to this ticket but have not. I've got the following links opened to continue to work on this: http://www.nvnews.net/vbulletin/showthread.php?t=110418 http://en.wikipedia.org/wiki/Memory_Type_Range_Registers
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > This isn't an issue. You really only need write back or write combining, and in > > > fact write back is more efficient than write combining. > > > > > > Write combining basically says that your memory is write through (e.g. must be > > > written back to memory right away) but instead of listening to each and every > > > write its able to combine those writes. > > > > > > Write back allows the write to happen to the CPU cache and just mark the cache > > > dirty and the update will be sunk back to memory at a later time. > > > > > > For more details on PAT & MTRR, see the Intel Developers Manuals @ > > > http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html > > > > I take it back and should say that write combining is actually a super set on > > write back, so you are correct you will get improved performance there. > > Ok, thanks for the info. Do you have any idea how I could get a > write-combining MTRR entry? Do you need more information about my system? > Glad to hear from you! Sorry I have not answered you sooner Matthias. I am stepping back from maintaining nvidia-drivers but will try to remember to look into this for you.
I think thats because driver uses PAT instead of mtrr, because mtrrs are unapropriate for modern complex gpus. You can view current PAT entries by: cat /sys/kernel/debug/x86/pat_memtype_list
