From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Chakri n <chakriin5@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-pm <linux-pm@lists.linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>,
nfs@lists.sourceforge.net
Subject: Re: A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?)
Date: Fri, 28 Sep 2007 10:40:00 +0200 [thread overview]
Message-ID: <1190968800.31636.26.camel@twins> (raw)
In-Reply-To: <92cbf19b0709280127yba48b60wfe58e532944894ca@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]
[ please don't top-post! ]
On Fri, 2007-09-28 at 01:27 -0700, Chakri n wrote:
> On 9/27/07, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > On Thu, 2007-09-27 at 23:50 -0700, Andrew Morton wrote:
> >
> > > What we _don't_ want to happen is for other processes which are writing to
> > > other, non-dead devices to get collaterally blocked. We have patches which
> > > might fix that queued for 2.6.24. Peter?
> >
> > Nasty problem, don't do that :-)
> >
> > But yeah, with per BDI dirty limits we get stuck at whatever ratio that
> > NFS server/mount (?) has - which could be 100%. Other processes will
> > then work almost synchronously against their BDIs but it should work.
> >
> > [ They will lower the NFS-BDI's ratio, but some fancy clipping code will
> > limit the other BDIs their dirty limit to not exceed the total limit.
> > And with all these NFS pages stuck, that will still be nothing. ]
> >
> Thanks.
>
> The BDI dirty limits sounds like a good idea.
>
> Is there already a patch for this, which I could try?
v2.6.23-rc8-mm2
> I believe it works like this,
>
> Each BDI, will have a limit. If the dirty_thresh exceeds the limit,
> all the I/O on the block device will be synchronous.
>
> so, if I have sda & a NFS mount, the dirty limit can be different for
> each of them.
>
> I can set dirty limit for
> - sda to be 90% and
> - NFS mount to be 50%.
>
> So, if the dirty limit is greater than 50%, NFS does synchronously,
> but sda can work asynchronously, till dirty limit reaches 90%.
Not quite, the system determines the limit itself in an adaptive
fashion.
bdi_limit = total_limit * p_bdi
Where p is a faction [0,1], and is determined by the relative writeout
speed of the current BDI vs all other BDIs.
So if you were to have 3 BDIs (sda, sdb and 1 nfs mount), and sda is
idle, and the nfs mount gets twice as much traffic as sdb, the ratios
will look like:
p_sda: 0
p_sdb: 1/3
p_nfs: 2/3
Once the traffic exceeds the write speed of the device we build up a
backlog and stuff gets throttled, so these proportions converge to the
relative write speed of the BDIs when saturated with data.
So what can happen in your case is that the NFS mount is the only one
with traffic is will get a fraction of 1. If it then disconnects like in
your case, it will still have all of the dirty limit pinned for NFS.
However other devices will at that moment try to maintain a limit of 0,
which ends up being similar to a sync mount.
So they'll not get stuck, but they will be slow.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-09-28 8:40 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-28 6:32 A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?) Chakri n
2007-09-28 6:50 ` Andrew Morton
2007-09-28 6:59 ` Peter Zijlstra
2007-09-28 8:27 ` Chakri n
2007-09-28 8:40 ` Peter Zijlstra [this message]
2007-09-28 9:01 ` Chakri n
2007-09-28 9:12 ` Peter Zijlstra
2007-09-28 9:20 ` Chakri n
2007-09-28 9:23 ` Peter Zijlstra
2007-09-28 10:36 ` Chakri n
2007-09-28 13:28 ` Jonathan Corbet
2007-09-28 13:35 ` Peter Zijlstra
2007-09-28 16:45 ` [linux-pm] " Alan Stern
2007-09-29 1:27 ` Daniel Phillips
2007-09-28 18:04 ` Andrew Morton
2007-09-28 17:00 ` Trond Myklebust
2007-09-28 18:49 ` Andrew Morton
2007-09-28 18:48 ` Peter Zijlstra
2007-09-28 19:16 ` Andrew Morton
2007-10-02 13:36 ` Peter Zijlstra
2007-10-02 15:42 ` Randy Dunlap
2007-10-03 9:28 ` [PATCH] lockstat: documentation Peter Zijlstra
2007-10-03 9:35 ` Ingo Molnar
2007-09-28 19:16 ` A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?) Trond Myklebust
2007-09-28 19:26 ` Andrew Morton
2007-09-28 19:52 ` Trond Myklebust
2007-09-28 20:10 ` Andrew Morton
2007-09-28 20:32 ` Trond Myklebust
2007-09-28 20:43 ` Andrew Morton
2007-09-28 21:36 ` Chakri n
2007-09-28 23:33 ` Chakri n
2007-09-28 20:24 ` Daniel Phillips
2007-09-29 1:51 ` KDB? Daniel Phillips
2007-09-29 0:46 ` A unresponsive file system can hang all I/O in the system on linux-2.6.23-rc6 (dirty_thresh problem?) Daniel Phillips
[not found] ` <20070929110454.GA29861@mail.ustc.edu.cn>
2007-09-29 11:04 ` Fengguang Wu
2007-09-29 11:48 ` Peter Zijlstra
[not found] ` <20070929122842.GA5454@mail.ustc.edu.cn>
2007-09-29 12:28 ` Fengguang Wu
2007-09-29 14:43 ` Peter Zijlstra
2007-10-01 15:57 ` Chuck Ebbert
[not found] ` <20071002020040.GA5275@mail.ustc.edu.cn>
2007-10-02 2:00 ` [PATCH] writeback: avoid possible balance_dirty_pages() lockup on a light-load bdi Fengguang Wu
2007-10-02 2:14 ` Andrew Morton
[not found] ` <20071002121327.GA5718@mail.ustc.edu.cn>
2007-10-02 12:13 ` Fengguang Wu
[not found] ` <20071002132702.GA10967@mail.ustc.edu.cn>
2007-10-02 13:27 ` Fengguang Wu
2007-10-02 18:35 ` Chuck Ebbert
2007-10-03 12:46 ` richard kennedy
[not found] ` <20071004015053.GA5789@mail.ustc.edu.cn>
2007-10-04 1:50 ` Fengguang Wu
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=1190968800.31636.26.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=chakriin5@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=nfs@lists.sourceforge.net \
/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