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 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.