https://bugzilla.novell.com/show_bug.cgi?id=775694 https://bugzilla.novell.com/show_bug.cgi?id=775694#c6 --- Comment #6 from Jan Kara <jack@suse.com> 2012-08-16 10:26:13 UTC --- (In reply to comment #5)
(In reply to comment #4)
OK, then it gets more interesting and my patch isn't going to help. So the music is on a separate, otherwise unused disk.
And the information on the USB disk being read so it's not like we're waiting on data to be written to slow storage. Is there any possibility that a barrier due to the write on ext4 can cause a read on a ext3 USB stick to be delayed? No. Barriers (cache flushes in fact) are per disk and completely independent.
That means that the problem shouldn't be caused by disk being busy due to other IO. The only idea I have is that reclaim is too eager and reclaims some of the loaded music data / player executable (due to dirty pages from large copy putting stress to reclaim).
That seems unlikely, the amount of data needed by the music player should be so low that I find it hard to believe it's getting reclaimed that quickly. That said the most recent round of backports for the 3.1 kernel included a fix for keeping mapped file pages resident but I don't think it'll fix this particular problem but if you build a test kernel with your ext3 latency fixes then it'll also include those reclaim fixes. http://beta.suse.com/private/jack/775694/ has the test kernel with my ext3 latency fix build from openSUSE-12.1 branch as of yesterday. Hubert can you try running it?
We also know from https://lkml.org/lkml/2012/7/10/132 that read latencies for ext3 can be very bad. Yes, but only in presence of heavier writing to the same filesystem. So I don't think ext3 on the stick really matters. I guess gathering stack traces is the first good step, then we will see where to go from there...
-- 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.