Re: MTRR survey: better X performance on systems with 3G or more RAM
| From: D. Hugh Redelmeier h...@mimosa.com | | From: Bob Marcan bob.mar...@gmail.com | I'm quite surprised at your observations. | (The other thing I noticed is that your glxgears performance is very | very good. This may indicate that something else is going on. | Perhaps the intel driver now uses PAT. I'm going to ignore this | possibility for now.) I now think that recent open-source intel drivers use PAT. I don't have a suitable test box with Fedora but I've got one running Ununtu 8.10 and Ubuntu 9.04 beta. This is my ThinkPad x61t with 4GiB of RAM. - the video buffer's address range has an MTRR that is covered by another - under 8.10, performance is increased if the MTRRs are rearranged - under 9.04 beta performance is good even with the default MTRR setup. This matches Bob Marcan's observation with Fedora 10 on his box. Thanks, Bob, for your help. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: MTRR survey: better X performance on systems with 3G or more RAM
On Sun, 12 Apr 2009 23:58:38 -0400 (EDT) D. Hugh Redelmeier h...@mimosa.com wrote: == What I'd like to know about your system: Computer brand and model (or motherboard info): Supermicro C2SBA motherboard, Intel(R) Core(TM)2 Quad CPUQ9400 @ 2.66GHz video controller: Intel 82G33/G31 Express Integrated Graphics Controller X video driver: X.Org X Server 1.5.3, open source intel driver RAM: 8GB distro: Fedora 10 x86_64 MTRR problem: $ /home/bob/tmp/01/mtrr-uncover/mtrr-uncover Initial MTRR configuration: 1 0x0-0x1 write-back 3 0x0bf60-0x0bf7f uncachable 4 0x0bf80-0x0bfff uncachable 0 0x0c000-0x0 uncachable 2 0x2-0x23fff write-back Final MTRR configuration: 1' 0x0-0x07fff write-back 51' 0x08000-0x0bfff write-back 3 0x0bf60-0x0bf7f uncachable 4 0x0bf80-0x0bfff uncachable 50 0x1-0x1 write-back 2 0x2-0x23fff write-back Commands for /proc/mtrr to make these changes: disable=0 disable=1 base=0x0 size=0x08000 type=write-back base=0x08000 size=0x04000 type=write-back base=0x1 size=0x1 type=write-back Fix: mtrr-uncover works, didn't try enable_mtrr_cleanup glxgears performance change: Before: 12897 frames in 5.0 seconds = 2579.254 FPS 12993 frames in 5.0 seconds = 2598.539 FPS 12879 frames in 5.0 seconds = 2575.759 FPS 12998 frames in 5.0 seconds = 2599.503 FPS 12947 frames in 5.0 seconds = 2588.019 FPS 12713 frames in 5.0 seconds = 2542.563 FPS 13014 frames in 5.0 seconds = 2602.721 FPS 13012 frames in 5.0 seconds = 2602.385 FPS 13010 frames in 5.0 seconds = 2601.951 FPS 12875 frames in 5.0 seconds = 2574.983 FPS 12389 frames in 5.0 seconds = 2477.740 FPS Now: 13053 frames in 5.0 seconds = 2610.419 FPS 13054 frames in 5.0 seconds = 2610.695 FPS 13048 frames in 5.0 seconds = 2609.514 FPS 13055 frames in 5.0 seconds = 2610.974 FPS 13053 frames in 5.0 seconds = 2610.452 FPS 13053 frames in 5.0 seconds = 2610.499 FPS 13056 frames in 5.0 seconds = 2611.072 FPS 13055 frames in 5.0 seconds = 2610.906 FPS 13054 frames in 5.0 seconds = 2610.624 FPS 13054 frames in 5.0 seconds = 2610.766 FPS 13055 frames in 5.0 seconds = 2610.859 FPS 13056 frames in 5.0 seconds = 2611.037 FPS 13054 frames in 5.0 seconds = 2610.709 FPS 13050 frames in 5.0 seconds = 2609.839 FPS Best regards, Bob -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: MTRR survey: better X performance on systems with 3G or more RAM
| From: Bob Marcan bob.mar...@gmail.com Thanks very much for trying this. I'm quite surprised at your observations. It looks to me as if your video card's buffer needed to be uncovered but the performance you observed didn't improve significantly. I've never seen that before. I'm wondering if my instructions were not clear enough and as a result you ran the after test without the benefit of uncovering. (The other thing I noticed is that your glxgears performance is very very good. This may indicate that something else is going on. Perhaps the intel driver now uses PAT. I'm going to ignore this possibility for now.) mtrr-uncover without flags tells you what it would do. You need to run it as root with the --execute flag for it to actually do the MTRR adjustment. # /home/bob/tmp/01/mtrr-uncover/mtrr-uncover --execute The second thing that could imagine going wrong is that you might have rebooted after running mtrr-uncover --execute, before running glxgears. Rebooting wipes out any changes made by mtrr-uncover. Could you run mtrrr-uncover, with no flags, just before running glxgears? If the MTRRs have been adjusted correctly, mtrr-uncover's last output line should say: No changes made. In summary, here's what I'd like you to try: as superuser, fix MTRRs: /home/bob/tmp/01/mtrr-uncover/mtrr-uncover --execute restart X: CTRL-ALT-Backspace check that the MTRR changes stuck (expect No changes made): /home/bob/tmp/01/mtrr-uncover/mtrr-uncover check that X set write-combining (expect one line of output): grep write-combining /proc/mtrr check performance: glxgears Could you send me a copy of your /var/log/Xorg.0.log after this test? I don't think that there would be anything confidential in it. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
Re: MTRR survey: better X performance on systems with 3G or more RAM
D. Hugh Redelmeier wrote: == 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: I tried it on HW: Asus P5E-VM HDMI MB with G35 chipset video Intel GMA X3500, with intel driver 4GB RAM Fedora 10 with kernels 2.6.29.1-15.fc10.i686 and 2.6.29.1-15.fc10.i686.PAE (from koji). grep write-combining /proc/mtrr with both kernels produce no output, after boot with enable_mtrr_cleanup, grep write-combining /proc/mtrr gives on both kernels output: reg06: base=0x0d000 ( 3328MB), size= 256MB, count=2: write-combining And glxgears outputs: 1) kernel 2.6.29.1-15.fc10.i686 : before: 2262 frames in 5.0 seconds = 452.307 FPS 2272 frames in 5.0 seconds = 454.345 FPS 2262 frames in 5.0 seconds = 452.399 FPS 2262 frames in 5.0 seconds = 452.339 FPS after boot with enable_mtrr_cleanup: 7456 frames in 5.0 seconds = 1491.186 FPS 7456 frames in 5.0 seconds = 1491.004 FPS 7468 frames in 5.0 seconds = 1493.462 FPS 7469 frames in 5.0 seconds = 1493.752 FPS 7472 frames in 5.0 seconds = 1494.248 FPS 2) 2.6.29.1-15.fc10.i686.PAE : before: 2262 frames in 5.0 seconds = 452.368 FPS 2272 frames in 5.0 seconds = 454.229 FPS 2270 frames in 5.0 seconds = 453.898 FPS 2271 frames in 5.0 seconds = 454.167 FPS 2272 frames in 5.0 seconds = 454.309 FPS 2271 frames in 5.0 seconds = 454.163 FPS after boot with enable_mtrr_cleanup: 6270 frames in 5.0 seconds = 1253.902 FPS 6276 frames in 5.0 seconds = 1255.051 FPS 6276 frames in 5.0 seconds = 1255.004 FPS 6274 frames in 5.0 seconds = 1254.667 FPS 6223 frames in 5.0 seconds = 1244.498 FPS Performance with kernel without PAE support is (with enable_mtrr_cleanup) about 15% better compared to kernel with PAE. Compiling Your mtrr-uncover fails: cc -Wall -gmtrr-uncover.c -o mtrr-uncover mtrr-uncover.c:114: error: ‘mtrr_type’ redeclared as different kind of symbol /usr/include/asm/mtrr.h:70: error: previous declaration of ‘mtrr_type’ was here make: *** [mtrr-uncover] Error 1 My /usr/include/asm/mtrr.h at line 70 declare mtrr_type as (lines 68-70): ... /* In the Intel processor's MTRR interface, the MTRR type is always held in an 8 bit field: */ typedef __u8 mtrr_type; ... Regards, Franta Hanzlik -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
MTRR survey: better X performance on systems with 3G or more RAM
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@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
