Red Hat Bugzilla – Bug 124617
Slow writing to ide disk when onboard video enabled.
Last modified: 2007-11-30 17:10:43 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 Description of problem: Motherboard ASUS P4P800-VM, 2.8GHz HT CPU, 1GB Ram, WDC WD800JB-00ETA0 ATA DISK drive, AMIBIOS 08:00.9 10/31/03 ID PPVM1808. Tested with 2.4.22-1.2149.nptl, 2.4.22-1.2188.nptl & smp-2.4.22-1.2188.nptl kernels. If the onboard video (Intel Extreme Graphics 2) is used with the default "onboard video mem" bios setting of "Enabled, 8MB" the creation of a 100MB file of zeros takes approximately 15 sec (similar with 4MB setting). If the bios setting is changed to "Enabled, 16MB" the time drops to approx 1.5sec (similar time with 1MB & 32MB settings). If the onboard video is disabled and a pci board is used (tested with GeForce FX 5200) elapsed time is approx 0.6 sec. Unfortunately we do not have sufficient unutilised equipment to carry out a wider range of testing to eliminate bios or hardware. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.bios onboard video memsetting of 4MB or 8MB 2. 3. Actual Results: Slow performance (when compared to older machines running same OS) when disk writing is involved. Timing carried out using touch /$dir/da_zeros; time -p dd if=/dev/zero bs=1024 count=100000 of=/$dir/da_zeros; rm -f /$dir/da_zeros Expected Results: Above test completed in < 1 sec. On board video bios settings will have minimal or nil impact on disk performance. Additional info: No error message. Maybe similar to bug 111395. WinDoze uses of the same hardware do not report a noticeable performance hit.
how does /proc/mtrr look on this box ?
contents of mtrr as requested. reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1 reg01: base=0x20000000 ( 512MB), size= 256MB: write-back, count=1 reg02: base=0x30000000 ( 768MB), size= 128MB: write-back, count=1 reg03: base=0x38000000 ( 896MB), size= 64MB: write-back, count=1 reg04: base=0x3c000000 ( 960MB), size= 32MB: write-back, count=1 reg05: base=0x3e000000 ( 992MB), size= 16MB: write-back, count=1 reg06: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=2 Values do not change with bios video memsetting of 4MB, 8MB or 16MB. Correction to original bug submission "If the onboard video is disabled and a pci board is used" should of course have been "If the onboard video is disabled and an agp board is used"
The problem is your onboard graphics controller steals memory from your 1GB of main memory. We cover the main memory with a write-back MTRR. Normally we could do this with a single mtrr which looks like.. reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 But MTRRs have rules regarding their alignment and size (basically they have to be a power of 2 in size). Because of this, we end up having to use multiple MTRRs to cover ranges of memory that aren't a power of 2 in size. (In the above example you have 1008MB instead of 1024MB for example). There isn't much we can do about this. It's a hardware limitation, as the CPU only has a limited number of MTRRs. There is some work being done upstream to move away from MTRRs towards PAT (page attribute tables), which work on a finer granularity (every 4KB has a seperate entry), this isn't likely to get merged into Fedora any time soon however. Additionally, the use of an AGP graphics card releases pressure on the main memory. When you share that memory with onboard graphics, you have two things competing for memory bandwidth, so a performance hit is to be expected. The fact that the values don't change regardless of the bios video setting points to a BIOS bug. They should resize accordingly as more/less video memory is stolen from main memory. Can you double check that the 'slow' settings don't cause a change in /proc/mtrr ? If they don't, you may want to check for a BIOS update.
I'm say'd that a BIOS update will solve it. Either way i've found lots of docs talking about the problem and saying that putting the video card as 32Megs its the best solution (not considering flashing the BIOS), and at least it worked for me. The problem its sayd to be that some areas of the memory are considered to be cacheable (and should't be), and it makes everything do sloowww.. I also know that this only appears on the bigmem kernels (support over 900Megs, i believe). Here it is a interesting view of a soluction that i've found here -> http://seclists.org/lists/linux-kernel/2004/Jan/1902.html Why a lot of region??? I try to clear all mtrr on P4P800-VM and set the new one base on GA-8IGX: [root /]# echo "disable=5" >| /proc/mtrr [root /]# echo "disable=4" >| /proc/mtrr [root /]# echo "disable=3" >| /proc/mtrr [root /]# echo "disable=2" >| /proc/mtrr [root /]# echo "disable=1" >| /proc/mtrr [root /]# echo "disable=0" >| /proc/mtrr [root /]# echo "base=0x00000000 size=0x40000000 type=write-back" > /proc/mtrr [root /]# echo "base=0x3ff00000 size=0x00100000 type=uncachable" > /proc/mtrr Yes!! It work, My system come fast again. the new /proc/mtrr show below: [root /]# cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0x3ff00000 (1023MB), size= 1MB: uncachable, count=1 For your 2G RAM machine. You may change size of first region from 0x40000000 (1G) to 0x80000000 (2G). The value of base and size of second region base on your video RAM setting in BIOS. Hope this can help ...
Alexandre, thanks for that. It helped us a great deal when we upgraded our systems with extra memory and they became 10x slower. It took a while to pinpoint the problem, and your post finally solved it. Thanks again !
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/
David, We have this same problem with Red Hat Enterprise Linux 3 U3. I didn't even notice that it was reported for Fedora Core 1. If more information is necessary about the hardware configuration, let me know.
Hello all, Bios version 1014 for P4P800-VM fixes the problem (see www.asus.com). Thanx to the people bringing up the /proc/mtrr stuff, it helped us a lot. Note that the correct setting for mtrr can be calculated looking at /proc/iomem.