Re: [PATCH 1/3 v2] mm: Stop background writeback if there is other work queued for the thread

[Wu Fengguang <fengguang.wu@intel.com>]

On Sun, Aug 08, 2010 at 12:12:30PM +0800, Dave Chinner wrote:
> On Thu, Aug 05, 2010 at 04:45:35PM -0700, Andrew Morton wrote:
> > On Thu,  5 Aug 2010 20:53:17 +0200
> > Jan Kara <jack@suse.cz> wrote:
> > > ---
> > >  fs/fs-writeback.c |    8 ++++++++
> > >  1 files changed, 8 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> > > index d5be169..542471e 100644
> > > --- a/fs/fs-writeback.c
> > > +++ b/fs/fs-writeback.c
> > > @@ -633,6 +633,14 @@ static long wb_writeback(struct bdi_writeback *wb,
> > >  			break;
> > >  
> > >  		/*
> > > +		 * Background writeout and kupdate-style writeback are
> > > +		 * easily livelockable. Stop them if there is other work
> > > +		 * to do so that e.g. sync can proceed.
> > > +		 */
> > > +		if ((work->for_background || work->for_kupdate) &&
> > > +		    !list_empty(&wb->bdi->work_list))
> > > +			break;
> > > +		/*
> > 
> > So what happens if an application sits in a loop doing write&fsync to a
> > file?  The vm's call for help gets ignored and your data doesn't get
> > written back for three days??
> 
> To avoid the possibility of any such occurrence, perhaps requeuing
> the work rather than cancelling it would be better? i.e. stop, put
> it behind whatever work just came in and so when the new work
> completes, we restart the background/expiry based writeback?

That would be better. Ie. add a flag BDI_background_writeback to
indicate the background work should be started after finishing with
the queued works. bdi_start_background_writeback() can be modified to
simply set the bit and wake up the flusher thread.

Thanks,
Fengguang