Re: PATCH reduce impact of FIFREEZE on userland processes

[Dave Chinner]

On Sat, Dec 08, 2012 at 07:12:04AM -0500, Christoph Hellwig wrote:
> On Fri, Dec 07, 2012 at 11:42:55AM +1100, Dave Chinner wrote:
> > The problem wth doing this is that the sync can delay the freeze
> > process by quite some time under the exact conditions you describe.
> > If you want freeze to take effect immediately (i.e instantly stop
> > new modifications), then adding a sync will break this semantic.
> > THere are existing users of freeze that require this behaviour...
> 
> But that's only because he uses the big hammer sync_filesystem() which
> actually waits for I/O completion.  I agree that this is a bad idea,
> but if we'd just do a writeback_inodes_sb() call in this place that
> starts asynchronous writeout I think everyone would benefit.

The problem with that is that async writeback will block on IO
submission as soon as the disk backs up on congestion. It's
effectively still waiting on IO completions to occur, only now
indirectly through the request queue submission process.

Hence I think for the heavily loaded situations that are causing
freeze latency related issues, sync or async pre-flushes are going
to cause exactly the same delays to freezing writes....

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/