From: Wu Fengguang <fengguang.wu@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@linux.vnet.ibm.com>,
Dave Chinner <david@fromorbit.com>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
Itaru Kitayama <kitayama@cl.bb4u.ne.jp>,
Minchan Kim <minchan.kim@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH 5/6] writeback: try more writeback as long as something was written
Date: Tue, 19 Apr 2011 19:16:01 +0800 [thread overview]
Message-ID: <20110419111601.GA18961@localhost> (raw)
In-Reply-To: <20110419102016.GD5257@quack.suse.cz>
On Tue, Apr 19, 2011 at 06:20:16PM +0800, Jan Kara wrote:
> On Tue 19-04-11 11:00:08, Wu Fengguang wrote:
> > writeback_inodes_wb()/__writeback_inodes_sb() are not aggressive in that
> > they only populate possibly a subset of elegible inodes into b_io at
> > entrance time. When the queued set of inodes are all synced, they just
> > return, possibly with all queued inode pages written but still
> > wbc.nr_to_write > 0.
> >
> > For kupdate and background writeback, there may be more eligible inodes
> > sitting in b_dirty when the current set of b_io inodes are completed. So
> > it is necessary to try another round of writeback as long as we made some
> > progress in this round. When there are no more eligible inodes, no more
> > inodes will be enqueued in queue_io(), hence nothing could/will be
> > synced and we may safely bail.
> Let me understand your concern here: You are afraid that if we do
> for_background or for_kupdate writeback and we write less than
> MAX_WRITEBACK_PAGES, we stop doing writeback although there could be more
> inodes to write at the time we are stopping writeback - the two realistic
Yes.
> cases I can think of are:
> a) when inodes just freshly expired during writeback
> b) when bdi has less than MAX_WRITEBACK_PAGES of dirty data but we are over
> background threshold due to data on some other bdi. And then while we are
> doing writeback someone does dirtying at our bdi.
> Or do you see some other case as well?
>
> The a) case does not seem like a big issue to me after your changes to
Yeah (a) is not an issue with kupdate writeback.
> move_expired_inodes(). The b) case maybe but do you think it will make any
> difference?
(b) seems also weird. What in my mind is this for_background case.
Imagine 100 inodes
i0, i1, i2, ..., i90, i91, i99
At queue_io() time, i90-i99 happen to be expired and moved to s_io for
IO. When finished successfully, if their total size is less than
MAX_WRITEBACK_PAGES, nr_to_write will be > 0. Then wb_writeback() will
quit the background work (w/o this patch) while it's still over
background threshold.
This will be a fairly normal/frequent case I guess.
Thanks,
Fengguang
> Honza
> >
> > Jan raised the concern
> >
> > I'm just afraid that in some pathological cases this could
> > result in bad writeback pattern - like if there is some process
> > which manages to dirty just a few pages while we are doing
> > writeout, this looping could result in writing just a few pages
> > in each round which is bad for fragmentation etc.
> >
> > However it requires really strong timing to make that to (continuously)
> > happen. In practice it's very hard to produce such a pattern even if
> > it's possible in theory. I actually tried to write 1 page per 1ms with
> > this command
> >
> > write-and-fsync -n10000 -S 1000 -c 4096 /fs/test
> >
> > and do sync(1) at the same time. The sync completes quickly on ext4,
> > xfs, btrfs. The readers could try other write-and-sleep patterns and
> > check if it can block sync for longer time.
> >
> > CC: Jan Kara <jack@suse.cz>
> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> > ---
> > fs/fs-writeback.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > --- linux-next.orig/fs/fs-writeback.c 2011-04-19 10:18:30.000000000 +0800
> > +++ linux-next/fs/fs-writeback.c 2011-04-19 10:18:31.000000000 +0800
> > @@ -750,23 +750,23 @@ static long wb_writeback(struct bdi_writ
> > wrote += write_chunk - wbc.nr_to_write;
> >
> > /*
> > - * If we consumed everything, see if we have more
> > + * Did we write something? Try for more
> > + *
> > + * Dirty inodes are moved to b_io for writeback in batches.
> > + * The completion of the current batch does not necessarily
> > + * mean the overall work is done. So we keep looping as long
> > + * as made some progress on cleaning pages or inodes.
> > */
> > - if (wbc.nr_to_write <= 0)
> > + if (wbc.nr_to_write < write_chunk)
> > continue;
> > if (wbc.inodes_cleaned)
> > continue;
> > /*
> > - * Didn't write everything and we don't have more IO, bail
> > + * No more inodes for IO, bail
> > */
> > if (!wbc.more_io)
> > break;
> > /*
> > - * Did we write something? Try for more
> > - */
> > - if (wbc.nr_to_write < write_chunk)
> > - continue;
> > - /*
> > * Nothing written. Wait for some inode to
> > * become available for writeback. Otherwise
> > * we'll just busyloop.
> >
> >
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@linux.vnet.ibm.com>,
Dave Chinner <david@fromorbit.com>,
Trond Myklebust <Trond.Myklebust@netapp.com>,
Itaru Kitayama <kitayama@cl.bb4u.ne.jp>,
Minchan Kim <minchan.kim@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH 5/6] writeback: try more writeback as long as something was written
Date: Tue, 19 Apr 2011 19:16:01 +0800 [thread overview]
Message-ID: <20110419111601.GA18961@localhost> (raw)
In-Reply-To: <20110419102016.GD5257@quack.suse.cz>
On Tue, Apr 19, 2011 at 06:20:16PM +0800, Jan Kara wrote:
> On Tue 19-04-11 11:00:08, Wu Fengguang wrote:
> > writeback_inodes_wb()/__writeback_inodes_sb() are not aggressive in that
> > they only populate possibly a subset of elegible inodes into b_io at
> > entrance time. When the queued set of inodes are all synced, they just
> > return, possibly with all queued inode pages written but still
> > wbc.nr_to_write > 0.
> >
> > For kupdate and background writeback, there may be more eligible inodes
> > sitting in b_dirty when the current set of b_io inodes are completed. So
> > it is necessary to try another round of writeback as long as we made some
> > progress in this round. When there are no more eligible inodes, no more
> > inodes will be enqueued in queue_io(), hence nothing could/will be
> > synced and we may safely bail.
> Let me understand your concern here: You are afraid that if we do
> for_background or for_kupdate writeback and we write less than
> MAX_WRITEBACK_PAGES, we stop doing writeback although there could be more
> inodes to write at the time we are stopping writeback - the two realistic
Yes.
> cases I can think of are:
> a) when inodes just freshly expired during writeback
> b) when bdi has less than MAX_WRITEBACK_PAGES of dirty data but we are over
> background threshold due to data on some other bdi. And then while we are
> doing writeback someone does dirtying at our bdi.
> Or do you see some other case as well?
>
> The a) case does not seem like a big issue to me after your changes to
Yeah (a) is not an issue with kupdate writeback.
> move_expired_inodes(). The b) case maybe but do you think it will make any
> difference?
(b) seems also weird. What in my mind is this for_background case.
Imagine 100 inodes
i0, i1, i2, ..., i90, i91, i99
At queue_io() time, i90-i99 happen to be expired and moved to s_io for
IO. When finished successfully, if their total size is less than
MAX_WRITEBACK_PAGES, nr_to_write will be > 0. Then wb_writeback() will
quit the background work (w/o this patch) while it's still over
background threshold.
This will be a fairly normal/frequent case I guess.
Thanks,
Fengguang
> Honza
> >
> > Jan raised the concern
> >
> > I'm just afraid that in some pathological cases this could
> > result in bad writeback pattern - like if there is some process
> > which manages to dirty just a few pages while we are doing
> > writeout, this looping could result in writing just a few pages
> > in each round which is bad for fragmentation etc.
> >
> > However it requires really strong timing to make that to (continuously)
> > happen. In practice it's very hard to produce such a pattern even if
> > it's possible in theory. I actually tried to write 1 page per 1ms with
> > this command
> >
> > write-and-fsync -n10000 -S 1000 -c 4096 /fs/test
> >
> > and do sync(1) at the same time. The sync completes quickly on ext4,
> > xfs, btrfs. The readers could try other write-and-sleep patterns and
> > check if it can block sync for longer time.
> >
> > CC: Jan Kara <jack@suse.cz>
> > Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
> > ---
> > fs/fs-writeback.c | 16 ++++++++--------
> > 1 file changed, 8 insertions(+), 8 deletions(-)
> >
> > --- linux-next.orig/fs/fs-writeback.c 2011-04-19 10:18:30.000000000 +0800
> > +++ linux-next/fs/fs-writeback.c 2011-04-19 10:18:31.000000000 +0800
> > @@ -750,23 +750,23 @@ static long wb_writeback(struct bdi_writ
> > wrote += write_chunk - wbc.nr_to_write;
> >
> > /*
> > - * If we consumed everything, see if we have more
> > + * Did we write something? Try for more
> > + *
> > + * Dirty inodes are moved to b_io for writeback in batches.
> > + * The completion of the current batch does not necessarily
> > + * mean the overall work is done. So we keep looping as long
> > + * as made some progress on cleaning pages or inodes.
> > */
> > - if (wbc.nr_to_write <= 0)
> > + if (wbc.nr_to_write < write_chunk)
> > continue;
> > if (wbc.inodes_cleaned)
> > continue;
> > /*
> > - * Didn't write everything and we don't have more IO, bail
> > + * No more inodes for IO, bail
> > */
> > if (!wbc.more_io)
> > break;
> > /*
> > - * Did we write something? Try for more
> > - */
> > - if (wbc.nr_to_write < write_chunk)
> > - continue;
> > - /*
> > * Nothing written. Wait for some inode to
> > * become available for writeback. Otherwise
> > * we'll just busyloop.
> >
> >
> --
> Jan Kara <jack@suse.cz>
> SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-04-19 11:16 UTC|newest]
Thread overview: 131+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-19 3:00 [PATCH 0/6] writeback: moving expire targets for background/kupdate works Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:00 ` [PATCH 1/6] writeback: pass writeback_control down to move_expired_inodes() Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:00 ` [PATCH 2/6] writeback: the kupdate expire timestamp should be a moving target Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 7:02 ` Dave Chinner
2011-04-19 7:02 ` Dave Chinner
2011-04-19 7:20 ` Wu Fengguang
2011-04-19 7:20 ` Wu Fengguang
2011-04-19 9:31 ` Jan Kara
2011-04-19 9:31 ` Jan Kara
2011-04-19 3:00 ` [PATCH 3/6] writeback: sync expired inodes first in background writeback Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 7:35 ` Dave Chinner
2011-04-19 7:35 ` Dave Chinner
2011-04-19 9:57 ` Jan Kara
2011-04-19 9:57 ` Jan Kara
2011-04-19 12:56 ` Wu Fengguang
2011-04-19 13:46 ` Wu Fengguang
2011-04-19 13:46 ` Wu Fengguang
2011-04-20 1:21 ` Dave Chinner
2011-04-20 1:21 ` Dave Chinner
2011-04-20 2:53 ` Wu Fengguang
2011-04-20 2:53 ` Wu Fengguang
2011-04-21 0:45 ` Dave Chinner
2011-04-21 0:45 ` Dave Chinner
2011-04-21 2:06 ` Wu Fengguang
2011-04-21 2:06 ` Wu Fengguang
2011-04-21 3:01 ` Dave Chinner
2011-04-21 3:01 ` Dave Chinner
2011-04-21 3:59 ` Wu Fengguang
2011-04-21 3:59 ` Wu Fengguang
2011-04-21 4:10 ` Wu Fengguang
2011-04-21 4:10 ` Wu Fengguang
2011-04-21 4:36 ` Christoph Hellwig
2011-04-21 4:36 ` Christoph Hellwig
2011-04-21 6:36 ` Dave Chinner
2011-04-21 6:36 ` Dave Chinner
2011-04-21 16:04 ` Jan Kara
2011-04-21 16:04 ` Jan Kara
2011-04-22 2:24 ` Wu Fengguang
2011-04-22 2:24 ` Wu Fengguang
2011-04-22 21:12 ` Jan Kara
2011-04-22 21:12 ` Jan Kara
2011-04-26 5:37 ` Wu Fengguang
2011-04-26 5:37 ` Wu Fengguang
2011-04-26 14:30 ` Jan Kara
2011-04-26 14:30 ` Jan Kara
2011-04-20 7:38 ` Wu Fengguang
2011-04-20 7:38 ` Wu Fengguang
2011-04-21 1:01 ` Dave Chinner
2011-04-21 1:01 ` Dave Chinner
2011-04-21 1:47 ` Wu Fengguang
2011-04-21 1:47 ` Wu Fengguang
2011-04-19 3:00 ` [PATCH 4/6] writeback: introduce writeback_control.inodes_cleaned Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 9:47 ` Jan Kara
2011-04-19 9:47 ` Jan Kara
2011-04-19 3:00 ` [PATCH 5/6] writeback: try more writeback as long as something was written Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 10:20 ` Jan Kara
2011-04-19 10:20 ` Jan Kara
2011-04-19 11:16 ` Wu Fengguang [this message]
2011-04-19 11:16 ` Wu Fengguang
2011-04-19 21:10 ` Jan Kara
2011-04-19 21:10 ` Jan Kara
2011-04-20 7:50 ` Wu Fengguang
2011-04-20 7:50 ` Wu Fengguang
2011-04-20 15:22 ` Jan Kara
2011-04-20 15:22 ` Jan Kara
2011-04-21 3:33 ` Wu Fengguang
2011-04-21 4:39 ` Christoph Hellwig
2011-04-21 4:39 ` Christoph Hellwig
2011-04-21 6:05 ` Wu Fengguang
2011-04-21 6:05 ` Wu Fengguang
2011-04-21 16:41 ` Jan Kara
2011-04-21 16:41 ` Jan Kara
2011-04-22 2:32 ` Wu Fengguang
2011-04-22 2:32 ` Wu Fengguang
2011-04-22 21:23 ` Jan Kara
2011-04-22 21:23 ` Jan Kara
2011-04-21 7:09 ` Dave Chinner
2011-04-21 7:09 ` Dave Chinner
2011-04-21 7:14 ` Christoph Hellwig
2011-04-21 7:14 ` Christoph Hellwig
2011-04-21 7:52 ` Dave Chinner
2011-04-21 7:52 ` Dave Chinner
2011-04-21 8:00 ` Christoph Hellwig
2011-04-21 8:00 ` Christoph Hellwig
2011-04-19 3:00 ` [PATCH 6/6] NFS: return -EAGAIN when skipped commit in nfs_commit_unstable_pages() Wu Fengguang
2011-04-19 3:00 ` Wu Fengguang
2011-04-19 3:29 ` Trond Myklebust
2011-04-19 3:29 ` Trond Myklebust
2011-04-19 3:55 ` Wu Fengguang
2011-04-19 3:55 ` Wu Fengguang
2011-04-21 4:40 ` Christoph Hellwig
2011-04-21 4:40 ` Christoph Hellwig
2011-04-19 6:38 ` [PATCH 0/6] writeback: moving expire targets for background/kupdate works Dave Chinner
2011-04-19 6:38 ` Dave Chinner
2011-04-19 8:02 ` Wu Fengguang
2011-04-19 8:02 ` Wu Fengguang
2011-04-21 4:34 ` Christoph Hellwig
2011-04-21 4:34 ` Christoph Hellwig
2011-04-21 5:50 ` Wu Fengguang
2011-04-21 5:50 ` Wu Fengguang
2011-04-21 5:56 ` Christoph Hellwig
2011-04-21 5:56 ` Christoph Hellwig
2011-04-21 6:07 ` Wu Fengguang
2011-04-21 6:07 ` Wu Fengguang
2011-04-21 7:17 ` Christoph Hellwig
2011-04-21 7:17 ` Christoph Hellwig
2011-04-21 10:15 ` Wu Fengguang
2011-04-21 10:15 ` Wu Fengguang
-- strict thread matches above, loose matches on Subject: below --
2010-07-22 5:09 [PATCH 0/6] [RFC] writeback: try to write older pages first Wu Fengguang
2010-07-22 5:09 ` [PATCH 5/6] writeback: try more writeback as long as something was written Wu Fengguang
2010-07-22 5:09 ` Wu Fengguang
2010-07-22 5:09 ` Wu Fengguang
2010-07-23 17:39 ` Jan Kara
2010-07-23 17:39 ` Jan Kara
2010-07-26 12:39 ` Wu Fengguang
2010-07-26 12:39 ` Wu Fengguang
2010-07-26 11:01 ` Mel Gorman
2010-07-26 11:01 ` Mel Gorman
2010-07-26 11:39 ` Wu Fengguang
2010-07-26 11:39 ` 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=20110419111601.GA18961@localhost \
--to=fengguang.wu@intel.com \
--cc=Trond.Myklebust@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=jack@suse.cz \
--cc=kitayama@cl.bb4u.ne.jp \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@linux.vnet.ibm.com \
--cc=minchan.kim@gmail.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 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.