public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Dave Chinner <david@fromorbit.com>,
	Rik van Riel <riel@redhat.com>, Mel Gorman <mel@csn.ul.ie>,
	Christoph Hellwig <hch@infradead.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/18] writeback: sync expired inodes first in background writeback
Date: Wed, 25 May 2011 22:38:57 +0800	[thread overview]
Message-ID: <20110525143857.GA25536@localhost> (raw)
In-Reply-To: <20110524155205.GC5390@quack.suse.cz>

Kara,

On Tue, May 24, 2011 at 11:52:05PM +0800, Jan Kara wrote:
> On Tue 24-05-11 13:14:17, Wu Fengguang wrote:
> > A background flush work may run for ever. So it's reasonable for it to
> > mimic the kupdate behavior of syncing old/expired inodes first.
> > 
> > At each queue_io() time, first try enqueuing only newly expired inodes.
> > If there are zero expired inodes to work with, then relax the rule and
> > enqueue all dirty inodes.
>   Fengguang, I've been thinking about this change again (since the code is
> now easier to read - good work! - and so I realized some new consequences)

Thank you.

> and I was wondering: Assume there is one continuously redirtied file and
> untar starts in parallel. With the new logic, background writeback will
> never consider inodes that are not expired in this situation (we never
> switch to "all dirty inodes" phase - or even if we switched, we would just
> queue all inodes and then return back to queueing only expired inodes). So
> the net effect is that for 30 seconds we will be only continuously writing
> pages of the continuously dirtied file instead of (possibly older) pages of
> other files that are written. Is this really desirable? Wasn't the old
> behavior simpler and not worse than the new one?

Good question! Yes sadly in this case the new behavior could be worse
than the old one.

In fact this patch do not improve the small files (< 4MB) case at all,
except for the side effect that less unexpired inodes will leave in
s_io when the background work quit and the later kupdate work will
write less unexpired inodes.

And for the mixed small/large files case, it actually results in worse
behavior on your mentioned case.

However the root cause here is the file being _actively_ written to,
somehow a livelock scheme. We could add a simple livelock prevention
scheme that works for the common case of file appending:

- save i_size when the range_cyclic writeback starts from 0, for
  limiting the writeback scope
  
- when range_cyclic writeback hits the saved i_size, quit the current
  inode instead of immediately restarting from 0. This will not only
  avoid a possible extra seek, but also redirty_tail() the inode and
  hence get out of possible livelock.

The livelock prevention scheme may not only eliminate the undesirable
behavior you observed for this patch, but also prevent the "some old
pages may not get the chance to get written to disk in an actively
dirtied file" data security issue discussed in an old email. What do
you think?

Thanks,
Fengguang

> > --- linux-next.orig/fs/fs-writeback.c	2011-05-24 11:17:18.000000000 +0800
> > +++ linux-next/fs/fs-writeback.c	2011-05-24 11:17:18.000000000 +0800
> > @@ -718,7 +718,7 @@ static long wb_writeback(struct bdi_writ
> >  		if (work->for_background && !over_bground_thresh())
> >  			break;
> >  
> > -		if (work->for_kupdate) {
> > +		if (work->for_kupdate || work->for_background) {
> >  			oldest_jif = jiffies -
> >  				msecs_to_jiffies(dirty_expire_interval * 10);
> >  			wbc.older_than_this = &oldest_jif;
> > @@ -729,6 +729,7 @@ static long wb_writeback(struct bdi_writ
> >  		wbc.pages_skipped = 0;
> >  		wbc.inodes_cleaned = 0;
> >  
> > +retry:
> >  		trace_wbc_writeback_start(&wbc, wb->bdi);
> >  		if (work->sb)
> >  			__writeback_inodes_sb(work->sb, wb, &wbc);
> > @@ -752,6 +753,19 @@ static long wb_writeback(struct bdi_writ
> >  		if (wbc.inodes_cleaned)
> >  			continue;
> >  		/*
> > +		 * background writeback will start with expired inodes, and
> > +		 * if none is found, fallback to all inodes. This order helps
> > +		 * reduce the number of dirty pages reaching the end of LRU
> > +		 * lists and cause trouble to the page reclaim.
> > +		 */
> > +		if (work->for_background &&
> > +		    wbc.older_than_this &&
> > +		    list_empty(&wb->b_io) &&
> > +		    list_empty(&wb->b_more_io)) {
> > +			wbc.older_than_this = NULL;
> > +			goto retry;
> > +		}
> > +		/*
> >  		 * No more inodes for IO, bail
> >  		 */
> >  		if (!wbc.more_io)
> > 
> > 
> -- 
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR

  reply	other threads:[~2011-05-25 14:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-24  5:14 [PATCH 00/18] writeback fixes and cleanups for 2.6.40 (v4) Wu Fengguang
2011-05-24  5:14 ` [PATCH 01/18] writeback: introduce .tagged_writepages for the WB_SYNC_NONE sync stage Wu Fengguang
2011-05-24  5:14 ` [PATCH 02/18] writeback: update dirtied_when for synced inode to prevent livelock Wu Fengguang
2011-05-24  5:14 ` [PATCH 03/18] writeback: introduce writeback_control.inodes_cleaned Wu Fengguang
2011-05-24  5:14 ` [PATCH 04/18] writeback: try more writeback as long as something was written Wu Fengguang
2011-05-24  5:14 ` [PATCH 05/18] writeback: the kupdate expire timestamp should be a moving target Wu Fengguang
2011-05-24  5:14 ` [PATCH 06/18] writeback: sync expired inodes first in background writeback Wu Fengguang
2011-05-24 15:52   ` Jan Kara
2011-05-25 14:38     ` Wu Fengguang [this message]
2011-05-26 23:10       ` Jan Kara
2011-05-27 15:06         ` Wu Fengguang
2011-05-27 15:17       ` Wu Fengguang
2011-05-24  5:14 ` [PATCH 07/18] writeback: refill b_io iff empty Wu Fengguang
2011-05-24  5:14 ` [PATCH 08/18] writeback: split inode_wb_list_lock into bdi_writeback.list_lock Wu Fengguang
2011-05-24  5:14 ` [PATCH 09/18] writeback: elevate queue_io() into wb_writeback() Wu Fengguang
2011-05-24  5:14 ` [PATCH 10/18] writeback: avoid extra sync work at enqueue time Wu Fengguang
2011-05-24  5:14 ` [PATCH 11/18] writeback: add bdi_dirty_limit() kernel-doc Wu Fengguang
2011-05-24  5:14 ` [PATCH 12/18] writeback: skip balance_dirty_pages() for in-memory fs Wu Fengguang
2011-05-24  5:14 ` [PATCH 13/18] writeback: remove writeback_control.more_io Wu Fengguang
2011-05-24  5:14 ` [PATCH 14/18] writeback: remove .nonblocking and .encountered_congestion Wu Fengguang
2011-05-24  5:14 ` [PATCH 15/18] writeback: trace event writeback_single_inode Wu Fengguang
2011-05-24  5:14 ` [PATCH 16/18] writeback: trace event writeback_queue_io Wu Fengguang
2011-05-24  5:14 ` [PATCH 17/18] writeback: make writeback_control.nr_to_write straight Wu Fengguang
2011-05-24  5:14 ` [PATCH 18/18] writeback: rearrange the wb_writeback() loop Wu Fengguang
2011-05-29  7:34 ` [PATCH 00/18] writeback fixes and cleanups for 2.6.40 (v4) Sedat Dilek
  -- strict thread matches above, loose matches on Subject: below --
2011-05-19 21:45 [PATCH 00/18] writeback fixes and cleanups for 2.6.40 (v3) Wu Fengguang
2011-05-19 21:45 ` [PATCH 06/18] writeback: sync expired inodes first in background writeback Wu Fengguang

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=20110525143857.GA25536@localhost \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mel@csn.ul.ie \
    --cc=riel@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox