From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wu Fengguang Subject: Re: [PATCH 1/3 v2] mm: Stop background writeback if there is other work queued for the thread Date: Sun, 8 Aug 2010 15:29:49 +0800 Message-ID: <20100808072949.GA5332@localhost> References: <1281034399-13055-1-git-send-email-jack@suse.cz> <1281034399-13055-2-git-send-email-jack@suse.cz> <20100805164535.f28d8807.akpm@linux-foundation.org> <20100808041230.GF26402@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , Jan Kara , "linux-fsdevel@vger.kernel.org" , "hch@infradead.org" , "jaxboe@fusionio.com" To: Dave Chinner Return-path: Received: from mga03.intel.com ([143.182.124.21]:29228 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751214Ab0HHH3x (ORCPT ); Sun, 8 Aug 2010 03:29:53 -0400 Content-Disposition: inline In-Reply-To: <20100808041230.GF26402@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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 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