Bug 15463

Summary: DRI seems to clash with disk I/O
Product: Drivers Reporter: uzytkownik2 (uzytkownik2)
Component: Video(DRI - Intel)Assignee: drivers_video-dri-intel (drivers_video-dri-intel)
Status: RESOLVED DUPLICATE    
Severity: normal CC: chris, jbarnes, kuraga333
Priority: P1    
Hardware: All   
OS: Linux   
URL: https://bugzilla.gnome.org/show_bug.cgi?id=603758
Kernel Version: 2.6.31,2.6.32 Subsystem:
Regression: No Bisected commit-id:

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 ***