Bug 124617 - Slow writing to ide disk when onboard video enabled.
Slow writing to ide disk when onboard video enabled.
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Depends On:
  Show dependency treegraph
Reported: 2004-05-27 18:01 EDT by Barry Wright
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-29 16:28:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description Barry Wright 2004-05-27 18:01:10 EDT
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:

Steps to Reproduce:
1.bios onboard video memsetting of 4MB or 8MB

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.
Comment 1 Dave Jones 2004-06-19 11:52:47 EDT
how does /proc/mtrr look on this box ?
Comment 2 Barry Wright 2004-06-24 22:08:19 EDT
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"
Comment 3 Dave Jones 2004-07-03 13:31:01 EDT
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.
Comment 4 Alexandre Costa 2004-07-08 08:48:50 EDT
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 ->

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" >
[root /]# echo "base=0x3ff00000 size=0x00100000 type=uncachable" >

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 ...
Comment 5 Dag Wieers 2004-09-28 19:48:08 EDT
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 !
Comment 6 David Lawrence 2004-09-29 16:28:08 EDT
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

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/
Comment 7 Dag Wieers 2004-09-29 18:46:32 EDT

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.
Comment 8 flynn 2005-01-20 04:38:59 EST
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.

Note You need to log in before you can comment on or make changes to this bug.