lkml.org 
[lkml]   [2012]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH reduce impact of FIFREEZE on userland processes
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@fromorbit.com


\
 
 \ /
  Last update: 2012-12-10 04:01    [W:0.074 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site