From: Olaf Kirch <okir@suse.de>
To: trond.myklebust@fys.uio.no
Cc: Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de>,
Greg Banks <gnb@melbourne.sgi.com>,
ShantanuGoel <sgoel01@yahoo.com>,
nfs@lists.sourceforge.net
Subject: Re: [PATCH 2.6.3] Add write throttling to NFS client
Date: Thu, 26 Feb 2004 15:50:51 +0100 [thread overview]
Message-ID: <20040226145051.GE32597@suse.de> (raw)
In-Reply-To: <32952.207.214.87.84.1077802844.squirrel@webmail.uio.no>
On Thu, Feb 26, 2004 at 02:40:44PM +0100, Trond Myklebust wrote:
> To simply assert that "async" is somehow equivalent to "not important" is
> just plain wrong.
Agreed, and I also agree that my suggestion of always preferring sync
tasks over async tasks is simplistic. But I think the patch proposed
by Shantanu adds more complexity to an already overly complex rpc
implementation.
The general "unfairness" observed in writes is due to the fact that we
allow a writing process to dirty a large number of pages without blocking
for the actual IO. So if you write a large file, nfs_flushd can easily
saturate the transport (which is a good thing for performance) but it's
bad for sync tasks.
One problem is that currently, there seems to be no upper bound at all
on the number of write requests we schedule. So one step in the right
direction may be to check the number of backlogged tasks and refrain
from scheduling more write requests if it exceeds a certain threshold.
Applications doing lots of stats etc are punished so severely because
all these operations are synchronous. So if you have a maximum backlog
of N RPC requests, your average delay per sync rpc operation is O(N).
So I think it could help if nfs_flushd and friends check the transport
backlog before scheduling new writes. There should be tunables for
the minimum number of pending writes we're always permitted to
schedule, and a maximum backlog length.
To avoid any ugliness related to layering violations, you could use
"color" to tag different RPC requests rather than referring to "writes".
Of course, that's just changing the queuing, not real scheduling.
But that can be an advantage, too, because it keeps things relatively
simple.
BTW I think reading is much less of a problem. The number of readaheads
scheduled by generic_file_read is limited, so it's entirely different
from the "lets blow the router's fuse" approach of the NFS write code.
Olaf
--
Olaf Kirch | Stop wasting entropy - start using predictable
okir@suse.de | tempfile names today!
---------------+
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-02-26 14:55 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-25 2:22 [PATCH 2.6.3] Add write throttling to NFS client Shantanu Goel
2004-02-26 3:34 ` Greg Banks
2004-02-26 4:10 ` Shantanu Goel
2004-02-26 8:41 ` Olaf Kirch
2004-02-26 12:49 ` trond.myklebust
2004-02-26 13:20 ` Bogdan Costescu
2004-02-26 13:40 ` trond.myklebust
2004-02-26 14:50 ` Olaf Kirch [this message]
2004-02-26 16:24 ` Bogdan Costescu
2004-02-26 16:16 ` Bogdan Costescu
-- strict thread matches above, loose matches on Subject: below --
2004-02-25 3:19 Shantanu Goel
2004-02-26 17:22 Lever, Charles
2004-02-26 19:18 ` Bogdan Costescu
[not found] <20040301043316.69563.qmail@web12822.mail.yahoo.com>
2004-03-01 5:50 ` trond.myklebust
2004-03-01 6:52 Lever, Charles
[not found] <20040301065511.29682.qmail@web12824.mail.yahoo.com>
2004-03-01 7:49 ` trond.myklebust
[not found] <20040301081456.37082.qmail@web12823.mail.yahoo.com>
2004-03-01 17:38 ` trond.myklebust
[not found] ` <40437AE4.4030407@lehman.com>
2004-03-01 18:18 ` Bogdan Costescu
2004-03-01 18:58 ` trond.myklebust
[not found] ` <35345.207.214.87.84.1078167489.squirrel@webmail.uio.no>
2004-03-02 0:49 ` trond.myklebust
2004-03-01 18:48 ` trond.myklebust
[not found] ` <404387DD.5010205@lehman.com>
2004-03-01 19:03 ` trond.myklebust
[not found] <20040303032213.58494.qmail@web12823.mail.yahoo.com>
[not found] ` <40461CCC.5040609@lehman.com>
2004-03-03 18:35 ` Trond Myklebust
[not found] ` <40462D4C.1060006@lehman.com>
2004-03-03 23:27 ` Trond Myklebust
[not found] <20040303235442.31317.qmail@web12826.mail.yahoo.com>
2004-03-04 0:18 ` Trond Myklebust
2004-03-05 2:22 ` Trond Myklebust
2004-03-04 2:08 Lever, Charles
2004-03-04 2:13 ` Trond Myklebust
[not found] <20040306021648.85080.qmail@web12824.mail.yahoo.com>
2004-03-06 3:42 ` Trond Myklebust
[not found] <20040306035627.79190.qmail@web12822.mail.yahoo.com>
2004-03-06 4:15 ` Trond Myklebust
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=20040226145051.GE32597@suse.de \
--to=okir@suse.de \
--cc=bogdan.costescu@iwr.uni-heidelberg.de \
--cc=gnb@melbourne.sgi.com \
--cc=nfs@lists.sourceforge.net \
--cc=sgoel01@yahoo.com \
--cc=trond.myklebust@fys.uio.no \
/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.