On Tue, Mar 27, 2012 at 10:31:27AM -0400, Christoph Hellwig wrote: > Vivek, does CFQ still need any hints for this sort of handoff? > Christoph, I don't understand the issue enough to comment on it. Had a quick look at the patch. Looks like some action (writing log), has been moved to a worker thread. And in some cases (log force triggered flush, whatever it is), we seem to prefer to do it from the submitter's context. > > To avoid potential issues with "smart" IO schedulers, don't use the > > workqueue for log force triggered flushes. Instead, do them directly > > so that the log IO is done directly by the process issuing the log > > force and so doesn't get stuck on IO elevator queue idling > > incorrectly delaying the log IO from the workqueue. Dave, can you explain a bit more that how CFQ idling in the above case. You seem to be saying that if we do more idling if this operation is done from worker thread context. I don't udnerstand why. In general, one can run into issues with CFQ if there are two processes doing IO and they are dependent on each other for completion of IO. CFQ will not know about this dependency and might end up waiting for IO from one process while next IO will come from next process now. So I am not sure why "smart" IO schedulers will run into issues if we use a worker thread to do log IO. Also not sure, why same thing is right thing to do when it is not forced flush. Thanks Vivek _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
