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) 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
- 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)
- 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)
 Pulseaudio plays without problem and application seems to not notice there was any problem.
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.
(In reply to comment #1)
> Not sure this is actually a bug... if your system is swapping or low on
> 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 (low priority jobs probably should not free used buffers of high priority jobs) or some problems with swapping.
 Yes - I know that it is hard subsystem and I admire those who implemented it.
Is this not a side-effect of bug 12309?
*** This bug has been marked as a duplicate of bug 12309 ***