From: Fengguang Wu <wfg@mail.ustc.edu.cn>
To: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <peterz@infradead.org>,
jplatte@naasa.net, linux-kernel@vger.kernel.org,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mike Snitzer <snitzer@gmail.com>
Subject: Re: regression: 100% io-wait with 2.6.24-rcX
Date: Wed, 16 Jan 2008 13:14:09 +0800 [thread overview]
Message-ID: <400460464.27881@ustc.edu.cn> (raw)
Message-ID: <E1JF0bJ-0000zU-FG@localhost.localdomain> (raw)
In-Reply-To: <20080115214212.GB32428@elte.hu>
On Tue, Jan 15, 2008 at 10:42:13PM +0100, Ingo Molnar wrote:
>
> * Fengguang Wu <wfg@mail.ustc.edu.cn> wrote:
>
> > On Mon, Jan 14, 2008 at 12:41:26PM +0100, Peter Zijlstra wrote:
> > >
> > > On Mon, 2008-01-14 at 12:30 +0100, Joerg Platte wrote:
> > > > Am Montag, 14. Januar 2008 schrieb Fengguang Wu:
> > > >
> > > > > Joerg, this patch fixed the bug for me :-)
> > > >
> > > > Fengguang, congratulations, I can confirm that your patch fixed the bug! With
> > > > previous kernels the bug showed up after each reboot. Now, when booting the
> > > > patched kernel everything is fine and there is no longer any suspicious
> > > > iowait!
> > > >
> > > > Do you have an idea why this problem appeared in 2.6.24? Did somebody change
> > > > the ext2 code or is it related to the changes in the scheduler?
> > >
> > > It was Fengguang who changed the inode writeback code, and I guess the
> > > new and improved code was less able do deal with these funny corner
> > > cases. But he has been very good in tracking them down and solving them,
> > > kudos to him for that work!
> >
> > Thank you.
> >
> > In particular the bug is triggered by the patch named:
> > "writeback: introduce writeback_control.more_io to indicate more io"
> > That patch means to speed up writeback, but unfortunately its
> > aggressiveness has disclosed bugs in reiserfs, jfs and now ext2.
> >
> > Linus, given the number of bugs it triggered, I'd recommend revert
> > this patch(git commit 2e6883bdf49abd0e7f0d9b6297fc3be7ebb2250b). Let's
> > push it back to -mm tree for more testings?
>
> i dont think a revert at this stage is a good idea and i'm not sure
> pushing it back into -mm would really expose more of these bugs. And
> these are real bugs in filesystems - bugs which we want to see fixed
> anyway. You are also tracking down those bugs very fast.
>
> [ perhaps, if it's possible technically (and if it is clean enough), you
> might want to offer a runtime debug tunable that can be used to switch
> off the new aspects of your code. That would speed up testing, in case
> anyone suspects the new writeback code. ]
The patch is too aggressive in itself. We'd better not risk on it.
The iowait is only unpleasant not destructive. But it will hurt if
many users complaints. Comment says that "nfs_writepages() sometimes
bales out without doing anything."
However I have an improved and more safe patch now. It won't iowait
when nfs_writepages() bale out without increasing pages_skipped, or
even when some buggy filesystem forget to clear PAGECACHE_TAG_DIRTY.
(The magic lies in the first chunk below.)
Mike, you can use this one on 2.6.24.
---
fs/fs-writeback.c | 17 +++++++++++++++--
include/linux/writeback.h | 1 +
mm/page-writeback.c | 9 ++++++---
3 files changed, 22 insertions(+), 5 deletions(-)
--- linux.orig/fs/fs-writeback.c
+++ linux/fs/fs-writeback.c
@@ -284,7 +284,16 @@ __sync_single_inode(struct inode *inode,
* soon as the queue becomes uncongested.
*/
inode->i_state |= I_DIRTY_PAGES;
- requeue_io(inode);
+ if (wbc->nr_to_write <= 0)
+ /*
+ * slice used up: queue for next turn
+ */
+ requeue_io(inode);
+ else
+ /*
+ * somehow blocked: retry later
+ */
+ redirty_tail(inode);
} else {
/*
* Otherwise fully redirty the inode so that
@@ -479,8 +488,12 @@ sync_sb_inodes(struct super_block *sb, s
iput(inode);
cond_resched();
spin_lock(&inode_lock);
- if (wbc->nr_to_write <= 0)
+ if (wbc->nr_to_write <= 0) {
+ wbc->more_io = 1;
break;
+ }
+ if (!list_empty(&sb->s_more_io))
+ wbc->more_io = 1;
}
return; /* Leave any unwritten inodes on s_io */
}
--- linux.orig/include/linux/writeback.h
+++ linux/include/linux/writeback.h
@@ -62,6 +62,7 @@ struct writeback_control {
unsigned for_reclaim:1; /* Invoked from the page allocator */
unsigned for_writepages:1; /* This is a writepages() call */
unsigned range_cyclic:1; /* range_start is cyclic */
+ unsigned more_io:1; /* more io to be dispatched */
};
/*
--- linux.orig/mm/page-writeback.c
+++ linux/mm/page-writeback.c
@@ -558,6 +558,7 @@ static void background_writeout(unsigned
global_page_state(NR_UNSTABLE_NFS) < background_thresh
&& min_pages <= 0)
break;
+ wbc.more_io = 0;
wbc.encountered_congestion = 0;
wbc.nr_to_write = MAX_WRITEBACK_PAGES;
wbc.pages_skipped = 0;
@@ -565,8 +566,9 @@ static void background_writeout(unsigned
min_pages -= MAX_WRITEBACK_PAGES - wbc.nr_to_write;
if (wbc.nr_to_write > 0 || wbc.pages_skipped > 0) {
/* Wrote less than expected */
- congestion_wait(WRITE, HZ/10);
- if (!wbc.encountered_congestion)
+ if (wbc.encountered_congestion || wbc.more_io)
+ congestion_wait(WRITE, HZ/10);
+ else
break;
}
}
@@ -631,11 +633,12 @@ static void wb_kupdate(unsigned long arg
global_page_state(NR_UNSTABLE_NFS) +
(inodes_stat.nr_inodes - inodes_stat.nr_unused);
while (nr_to_write > 0) {
+ wbc.more_io = 0;
wbc.encountered_congestion = 0;
wbc.nr_to_write = MAX_WRITEBACK_PAGES;
writeback_inodes(&wbc);
if (wbc.nr_to_write > 0) {
- if (wbc.encountered_congestion)
+ if (wbc.encountered_congestion || wbc.more_io)
congestion_wait(WRITE, HZ/10);
else
break; /* All the old data is written */
next prev parent reply other threads:[~2008-01-16 5:14 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-07 10:51 regression: 100% io-wait with 2.6.24-rcX Joerg Platte
2008-01-07 11:19 ` Ingo Molnar
2008-01-07 13:24 ` Joerg Platte
2008-01-07 13:32 ` Peter Zijlstra
2008-01-07 13:40 ` Joerg Platte
[not found] ` <E1JCRbA-0002bh-3c@localhost.localdomain>
2008-01-09 3:27 ` Fengguang Wu
2008-01-09 6:13 ` Joerg Platte
[not found] ` <E1JCZg2-0001DE-RP@localhost.localdomain>
2008-01-09 12:04 ` Fengguang Wu
2008-01-09 12:22 ` Joerg Platte
[not found] ` <E1JCaUd-0001Ko-Tt@localhost.localdomain>
2008-01-09 12:57 ` Fengguang Wu
2008-01-09 13:04 ` Joerg Platte
[not found] ` <E1JCrMj-0001HR-SZ@localhost.localdomain>
2008-01-10 6:58 ` Fengguang Wu
[not found] ` <E1JCrsE-0000v4-Dz@localhost.localdomain>
2008-01-10 7:30 ` Fengguang Wu
[not found] ` <20080110073046.GA3432@mail.ustc.edu.cn>
[not found] ` <E1JCsDr-0002cl-0e@localhost.localdomain>
2008-01-10 7:53 ` Fengguang Wu
2008-01-10 8:37 ` Joerg Platte
[not found] ` <E1JCt0n-00048n-AD@localhost.localdomain>
2008-01-10 8:43 ` Fengguang Wu
2008-01-10 10:03 ` Joerg Platte
[not found] ` <E1JDBk4-0000UF-03@localhost.localdomain>
2008-01-11 4:43 ` Fengguang Wu
2008-01-11 5:29 ` Joerg Platte
2008-01-11 6:41 ` Joerg Platte
2008-01-12 23:32 ` Joerg Platte
[not found] ` <E1JDwaA-00017Q-W6@localhost.localdomain>
2008-01-13 6:44 ` Fengguang Wu
2008-01-13 8:05 ` Joerg Platte
[not found] ` <E1JDy5a-0001al-Tk@localhost.localdomain>
2008-01-13 8:21 ` Fengguang Wu
2008-01-13 9:49 ` Joerg Platte
[not found] ` <E1JE1Uz-0002w5-6z@localhost.localdomain>
2008-01-13 11:59 ` Fengguang Wu
[not found] ` <20080113115933.GA11045@mail.ustc.edu.cn>
[not found] ` <E1JEGPH-0001uw-Df@localhost.localdomain>
2008-01-14 3:54 ` Fengguang Wu
[not found] ` <20080114035439.GA7330@mail.ustc.edu.cn>
[not found] ` <E1JEM2I-00010S-5U@localhost.localdomain>
2008-01-14 9:55 ` Fengguang Wu
2008-01-14 11:30 ` Joerg Platte
2008-01-14 11:41 ` Peter Zijlstra
[not found] ` <E1JEOmD-0001Ap-U7@localhost.localdomain>
2008-01-14 12:50 ` Fengguang Wu
2008-01-15 21:13 ` Mike Snitzer
[not found] ` <E1JF0m1-000101-OK@localhost.localdomain>
2008-01-16 5:25 ` Fengguang Wu
2008-01-15 21:42 ` Ingo Molnar
[not found] ` <E1JF0bJ-0000zU-FG@localhost.localdomain>
2008-01-16 5:14 ` Fengguang Wu [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-01-16 9:26 Martin Knoblauch
[not found] ` <E1JF6w8-0000vs-HM@localhost.localdomain>
2008-01-16 12:00 ` Fengguang Wu
2008-01-16 14:15 Martin Knoblauch
2008-01-16 16:27 ` Mike Snitzer
2008-01-17 13:52 Martin Knoblauch
2008-01-17 16:11 ` Mike Snitzer
2008-01-17 17:44 Martin Knoblauch
2008-01-17 20:23 ` Mel Gorman
2008-01-17 17:51 Martin Knoblauch
2008-01-17 21:50 Martin Knoblauch
2008-01-17 22:12 ` Mel Gorman
2008-01-18 8:19 Martin Knoblauch
2008-01-18 16:01 ` Mel Gorman
2008-01-18 17:46 ` Linus Torvalds
2008-01-18 19:01 ` Martin Knoblauch
2008-01-18 19:23 ` Linus Torvalds
2008-01-22 14:39 ` Alasdair G Kergon
2008-01-18 20:00 ` Mike Snitzer
2008-01-18 22:47 ` Mike Snitzer
2008-01-19 10:24 Martin Knoblauch
2008-01-22 15:25 Martin Knoblauch
2008-01-22 23:40 ` Alasdair G Kergon
2008-01-22 18:51 Martin Knoblauch
2008-01-23 11:12 Martin Knoblauch
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=400460464.27881@ustc.edu.cn \
--to=wfg@mail.ustc.edu.cn \
--cc=akpm@linux-foundation.org \
--cc=jplatte@naasa.net \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=snitzer@gmail.com \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox