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

[Dave Chinner <david@fromorbit.com>]

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?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com