https://bugzilla.novell.com/show_bug.cgi?id=775694 https://bugzilla.novell.com/show_bug.cgi?id=775694#c1 --- Comment #1 from Mel Gorman <mgorman@suse.com> 2012-08-14 16:00:20 UTC --- (In reply to comment #0)
When one process is doing significant I/O, no other process can read or write data and is suspended until the first process finally finishes.
1. The bug is against openSUSE 12.1 but what kernel version are you using exactly? 2. What filesystem? 3. Is the filesystem you are doing the significant IO on and the music the same filesystem? 4. Are barriers enabled? If so, what is the experience if they are disabled? 5. What is the value of /proc/sys/vm/dirty_ratio? If it's high (like 40), what is the experience if it's lower like 10?
How to reproduce:
Play some music with your favorite music player. Then in some shell, type something like:
cp -a hugefile.in hugefile.out
after some seconds, music will stop playing and only continue after the cp has finished. I'm currently copying a 53 GB file and music stopped more than one minute ago!
I do not see the same problem as such but I do know that IO interactivity for the 3.1 kernel was particularly bad. If there is a lot of different IO requests then I would sometimes see a process stall for a long period of time waiting on log space for ext4. This was later fixed but not all the fixes were not backported. I recently backported a second round of patches related to excessive reclaim and stalls while copying to USB. I do not believe a kernel has been released with them yet but I could build a test kernel if you wanted to try it. However, it's not exactly the same problem On a similar note, have you tried the tumbleweed kernel? It should be 3.4 based.
<SNIP> Meanwhile the "cp" has finished and music continues to play. After 2 (TWO!!!) minutes. On a system with 8 GB RAM and core-7 processor.
The number of cores is not as important if they are stalled waiting on access to storage. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.