From: Andrea Arcangeli <andrea@suse.de>
To: Dave Kleikamp <shaggy@austin.ibm.com>
Cc: Valdis.Kletnieks@vt.edu, Con Kolivas <kernel@kolivas.org>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.14-rc2-mm1 - ext3 wedging up
Date: Thu, 29 Sep 2005 00:38:29 +0200 [thread overview]
Message-ID: <20050928223829.GH10408@opteron.random> (raw)
In-Reply-To: <1127511979.8875.11.camel@kleikamp.austin.ibm.com>
On Fri, Sep 23, 2005 at 04:46:19PM -0500, Dave Kleikamp wrote:
> On Fri, 2005-09-23 at 15:59 -0500, Dave Kleikamp wrote:
> I'd guess that it's spinning in balance_dirty_pages.
> /proc/<pid>/future_dirty is 25650 for fsx. It appears that
> nr_reclaimable is not going to zero for some reason.
Even if nr_reclaimable isn't going to zero, eventually the loop should
break out because pages_written must increase.
So this make me think it might be the nr_unstable that destabilizes it,
and whatever it is, it is a bug in mainline as well, except it was well
hidden until now, because the dirty levels never approached zero during
heavy write-IO like it can happen with this feature enabled.
Basically whatever we account as "reclaimable" must be _written_out_ and
accounted as well in the "pages_written" otherwise it'll just hang.
If there's a problem, it shall be a longstanding one.
Can you try with this new patch that stops accounting "unstable" as
"reclaimable". It should be possible to flush the dirty pages to disk so
"nr_dirty" should be safe because they should always increase the
"pages_written". I'm not sure if this fixes it, but this at least rule
out the nfs from the equation (perhaps nfs will never be accounted as
"pages_written" and that would be a possible explanation of the infinite
loop).
This new update also makes sure to never account rewrites (except for
reiserfs where it's more difficult to change the code for this).
I tried with fsx (no params) but I couldn't reproduce any problem yet,
but I've no nfs workload involved in my test box.
http://www.kernel.org/pub/linux/kernel/people/andrea/patches/v2.6/2.6.14-rc1/per-task-predictive-write-throttling-4
thanks for the help!
next prev parent reply other threads:[~2005-09-28 22:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-22 19:59 2.6.14-rc2-mm1 - ext3 wedging up Valdis.Kletnieks
2005-09-23 0:36 ` Con Kolivas
2005-09-23 7:20 ` Valdis.Kletnieks
2005-09-23 8:45 ` Andrea Arcangeli
2005-09-23 14:24 ` Dave Kleikamp
2005-09-23 9:45 ` Con Kolivas
2005-09-23 15:31 ` Andrea Arcangeli
2005-09-23 19:11 ` Valdis.Kletnieks
2005-09-23 20:57 ` Dave Kleikamp
2005-09-23 20:59 ` Dave Kleikamp
2005-09-23 21:46 ` Dave Kleikamp
2005-09-26 8:14 ` Andrea Arcangeli
2005-09-28 22:38 ` Andrea Arcangeli [this message]
2005-10-01 0:27 ` Dave Kleikamp
2005-10-02 10:27 ` Andrea Arcangeli
2005-10-02 10:32 ` Andrea Arcangeli
2005-10-02 13:51 ` Dave Kleikamp
2005-10-03 18:06 ` Dave Kleikamp
2005-10-03 18:31 ` Valdis.Kletnieks
2005-10-10 17:15 ` Andrea Arcangeli
2005-10-10 17:21 ` Dave Kleikamp
2005-10-03 1:04 ` Valdis.Kletnieks
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=20050928223829.GH10408@opteron.random \
--to=andrea@suse.de \
--cc=Valdis.Kletnieks@vt.edu \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shaggy@austin.ibm.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