[Top] [All Lists]

Re: [PATCH] xfs: Do background CIL flushes via a workqueue

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs: Do background CIL flushes via a workqueue
From: Vivek Goyal <vgoyal@xxxxxxxxxx>
Date: Tue, 27 Mar 2012 11:57:59 -0400
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20120327143127.GA11434@xxxxxxxxxxxxx>
References: <1332841605-3538-1-git-send-email-david@xxxxxxxxxxxxx> <20120327143127.GA11434@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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

> > 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.


<Prev in Thread] Current Thread [Next in Thread>