Bug 15463 - DRI seems to clash with disk I/O
DRI seems to clash with disk I/O
Status: RESOLVED DUPLICATE of bug 12309
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel)
All Linux
: P1 normal
Assigned To: drivers_video-dri-intel@kernel-bugs.osdl.org
https://bugzilla.gnome.org/show_bug.c...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-06 21:52 UTC by uzytkownik2@gmail.com
Modified: 2010-08-06 08:28 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.31,2.6.32
Tree: Mainline
Regression: No


Attachments

Description uzytkownik2@gmail.com 2010-03-06 21:52:31 UTC
It seems like DRI is tightly connected with performance with disk I/O.

 - When there is application with nice 19, ionice Idle and batch scheduler when works heavily on I/O (iotop reports 2-3 MB/s transfers) the GL applications have significant delays. No other application uses I/O.
 - At seamingly random moments (however they might indicate GL operations as it is during for example  playing movie[1]) the screen is blocked for a moment and the hard drive LED (on notebook panel) is turned on as if I/O operation was performed. No application which would do such operations is opened . However I cannot verify this as screen is blocked

System:
 - glibc 6.10
 - xorg-server 1.7.5 (and some earier versions)
 - xf86-video-intel 2.9.1 (and some earier versions)
 - linux 2.6.31 & 2.6.32
 - mesa 7.7 rc1 (and some earier versions)

Hardware
 - ThinkPad T500 2242 CTO
 - Intel® Core™2 Duo T9600
 - 2 GiB 1066MHz DDR3 SODIMM memory. Top after the artefact does not indicate any swapping
 - Intel GMA 4500MHD
 - 320GB 7200rpm SATA/1.5 (UDMA/133 - using UDMA/100)

[1] Pulseaudio plays without problem and application seems to not notice there was any problem.
Comment 1 Jesse Barnes 2010-07-23 19:58:42 UTC
Not sure this is actually a bug... if your system is swapping or low on memory, the kernel will have to swap graphics related pages as well, potentially stalling graphical applications during disk I/O.
Comment 2 uzytkownik2@gmail.com 2010-07-25 19:36:54 UTC
(In reply to comment #1)
> Not sure this is actually a bug... if your system is swapping or low on memory,
> the kernel will have to swap graphics related pages as well, potentially
> stalling graphical applications during disk I/O.

If the only <1 GiB is used and *no* swap is used (unless 4-10 MiB of swap used is worth mentioned when >1024 MiB is 'free' [used on buffer or cache]) it is error. 

After upgrading to 4 GiB problem was solved but it is not a statement that to use Intel cards and use I/O you have to have 2-3 GiB free.

1. Low priority jobs should *not* *significantly* affect normal. If an application have priority 19 and lowest io and scheduler priority it should *not* cause visible delays in applications
2. With similar conditions (no I/O, no swap occupied) there is no reason system would swap.

In short - system have no reason to do heavy swapping. Either it's some error in subsystem design/implementation[1] (low priority jobs probably should not free used buffers of high priority jobs) or some problems with swapping.

[1] Yes - I know that it is hard subsystem and I admire those who implemented it.
Comment 3 Chris Wilson 2010-08-06 08:22:12 UTC
Is this not a side-effect of bug 12309?
Comment 4 uzytkownik2@gmail.com 2010-08-06 08:28:26 UTC
Very likely

*** This bug has been marked as a duplicate of bug 12309 ***

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