All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jaxboe@fusionio.com>
To: Wu Fengguang <fengguang.wu@intel.com>
Cc: Dave Chinner <david@fromorbit.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jan Kara <jack@suse.cz>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"hch@infradead.org" <hch@infradead.org>
Subject: Re: [PATCH 1/3 v2] mm: Stop background writeback if there is other work queued for the thread
Date: Sun, 8 Aug 2010 07:07:26 -0400	[thread overview]
Message-ID: <4C5E8FEE.4080209@fusionio.com> (raw)
In-Reply-To: <20100808072949.GA5332@localhost>

On 08/08/2010 03:29 AM, Wu Fengguang wrote:
> 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.

I think that is better, we ideally want background writeout to
interleave smoothly with any other write activity. But why not just
mark the 'background writeout was interrupted' bit here when breaking,
and have the thread check-clear that when finishing some other piece
of work (or when going idle)?

-- 
Jens Axboe


Confidentiality Notice: This e-mail message, its contents and any attachments to it are confidential to the intended recipient, and may contain information that is privileged and/or exempt from disclosure under applicable law. If you are not the intended recipient, please immediately notify the sender and destroy the original e-mail message and any attachments (and any copies that may have been made) from your system or otherwise. Any unauthorized use, copying, disclosure or distribution of this information is strictly prohibited.

  reply	other threads:[~2010-08-08 11:07 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-05 18:53 [PATCH 0/3 v2] Three writeback fixes to stop sync(1) livelocks Jan Kara
2010-08-05 18:53 ` [PATCH 1/3 v2] mm: Stop background writeback if there is other work queued for the thread Jan Kara
2010-08-05 19:38   ` Jens Axboe
2010-08-05 23:45   ` Andrew Morton
2010-08-07 16:04     ` Wu Fengguang
2010-08-08  2:43     ` Jan Kara
2010-08-08  3:10       ` Wu Fengguang
2010-08-08  4:12     ` Dave Chinner
2010-08-08  7:29       ` Wu Fengguang
2010-08-08 11:07         ` Jens Axboe [this message]
2010-08-08 13:59           ` Jan Kara
2010-08-08 22:55             ` Wu Fengguang
2010-08-05 18:53 ` [PATCH 2/3 v2] mm: Fix writeback_in_progress() Jan Kara
2010-08-05 19:37   ` Jens Axboe
2010-08-05 23:06   ` Wu Fengguang
2010-08-06  0:10   ` Andrew Morton
2010-08-08  2:25     ` Jan Kara
2010-08-05 18:53 ` [PATCH 3/3 v2] mm: Avoid resetting wb_start after each writeback round Jan Kara
2010-08-05 19:38   ` Jens Axboe
2010-08-06  0:21   ` Andrew Morton
2010-08-07 22:45     ` Jan Kara
2010-08-06 12:23 ` [PATCH 0/3 v2] Three writeback fixes to stop sync(1) livelocks Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C5E8FEE.4080209@fusionio.com \
    --to=jaxboe@fusionio.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=fengguang.wu@intel.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.