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.
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 > 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.
Is this not a side-effect of bug 12309?
Very likely *** This bug has been marked as a duplicate of bug 12309 ***