From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH 1/3 v2] mm: Stop background writeback if there is other work queued for the thread Date: Thu, 5 Aug 2010 16:45:35 -0700 Message-ID: <20100805164535.f28d8807.akpm@linux-foundation.org> References: <1281034399-13055-1-git-send-email-jack@suse.cz> <1281034399-13055-2-git-send-email-jack@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, hch@infradead.org, jaxboe@fusionio.com, Wu Fengguang To: Jan Kara Return-path: Received: from smtp1.linux-foundation.org ([140.211.169.13]:45777 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757203Ab0HEXyI (ORCPT ); Thu, 5 Aug 2010 19:54:08 -0400 In-Reply-To: <1281034399-13055-2-git-send-email-jack@suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, 5 Aug 2010 20:53:17 +0200 Jan Kara wrote: > Background writeback and kupdate-style writeback What the heck's the difference between "Background writeback" and "kupdate-style" writeback? afacit "background" means "not due to kupdate, but due to a vmscan poke or something like that". But the terms aren't defined anywhere and the wb_writeback_work fields are uncommented and the functions are undocumented and no wonder we keep making such a mess of this code. > are easily livelockable (from > a definition of their target). Please fully describe the livelock scenario(s). > This is inconvenient because it can make sync(1) > stall forever waiting on its queued work to be finished. And please fully describe the reason for the stall of sync(1). Because if these things _are_ described then others are in a better position to review your proposed fix and they are in a better position to propose alternative fixes, no? > Generally, if someone > has a particular requirement for writeback he needs, it makes sense to give it > preference over a generic background dirty page cleaning. As soon as that work > is done, flusher thread will return back to background cleaning if it is > needed. So lets just interrupt background and kupdate writeback if there is > some other work to do to fix the livelocking problem. > > CC: hch@infradead.org > Reviewed-by: Wu Fengguang > Signed-off-by: Jan Kara > --- > 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??