On Mon, 2008-07-21 at 15:23 -0400, Ric Wheeler wrote: > >>> [ lock timeouts and stalls ] > >>> > >>> > >>> Ok, I've made a few changes that should lower overall contenion on the > >>> allocation mutex. I'm getting better performance on a 3 million file > >>> run, please give it a shot. > >> > >> After an update, clean rebuild & reboot, the test is running along and > >> has hit about 10 million files. I still see some messages like: > >> > >> INFO: task pdflush:4051 blocked for more than 120 seconds.
The latest code in btrfs-unstable has everything I can safely do right now :) Basically the stalls come from someone doing IO with the allocation mutex held. It is surprising that we should be stalling for such a long time, it is probably a mixture of elevator starvation and btrfs fun. But, btrfs-unstable also has code to replace the page lock with a per-tree block mutex, which will allow me to get rid of the big allocation mutex over the long term. I was able to break up most of the long operations and have them drop/reacquire the allocation mutex to prevent this starvation most of the time. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
