On 06/09/2011 10:32 PM, Vivek Goyal wrote: > On Thu, Jun 09, 2011 at 10:21:33AM -0400, Christoph Hellwig wrote: >> On Thu, Jun 09, 2011 at 10:12:38PM +0800, Tao Ma wrote: >>> Just want to say more about the situation here. Actually the flusher is >>> too much easier to be blocked by the sync requests. And whenever it is >>> blocked, it takes a quite long time to get back(because several cfq >>> designs), so do you think we can use WRITE_SYNC for the bdev inodes in >>> flusher? AFAICS, in most of the cases when a volume is mounted, the >>> writeback for a bdev inode means the metadata writeback. And they are >>> very important for a file system and should be written as far as >>> possible. I ran my test cases with the change, and now the livelock >>> doesn't show up anymore. >> >> It's not a very good guestimate for metadata. A lot of metadata is >> either stored in directories (often happens for directories) or doesn't >> use the pagecache writeback functions at all. >> >> The major problem here seems to be that async requests simply starve >> sync requests far too much. > > You mean sync requests starve async requests? > > It is possible that CFQ can starve async requests for long time in > presence of sync reqeusts. If that's the case, all the reported issues > should go away with deadline scheduler. > > As I mentioned in other mail, one commit made the dias very heavily > loaded in favor of sync requests. > > commit f8ae6e3eb8251be32c6e913393d9f8d9e0609489 > Author: Shaohua Li <shaohua.li@xxxxxxxxx> > Date: Fri Jan 14 08:41:02 2011 +0100 > > block cfq: make queue preempt work for queues from different workload > > > I will do some quick tests and try to write a small patch where we can > keep track of how many times sync and async workloads have been scheduled > and make sure we don't starve async req completely. oh, so you mean the patch is the culprit? I will try to revert it to see whether the system works better. Regards, Tao -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
