Messages in this thread | | | Subject | Re: [PATCH] nfs: fix congestion control | From | Trond Myklebust <> | Date | Tue, 16 Jan 2007 17:27:46 -0500 |
| |
On Tue, 2007-01-16 at 23:08 +0100, Peter Zijlstra wrote: > Subject: nfs: fix congestion control > > The current NFS client congestion logic is severely broken, it marks the > backing device congested during each nfs_writepages() call and implements > its own waitqueue. > > Replace this by a more regular congestion implementation that puts a cap > on the number of active writeback pages and uses the bdi congestion waitqueue. > > NFSv[34] commit pages are allowed to go unchecked as long as we are under > the dirty page limit and not in direct reclaim. > > A buxom young lass from Neale's Flat, > Bore triplets, named Matt, Pat and Tat. > "Oh Lord," she protested, > "'Tis somewhat congested ... > "You've given me no tit for Tat."
What on earth is the point of adding congestion control to COMMIT? Strongly NACKed.
Why 16MB of on-the-wire data? Why not 32, or 128, or ... Solaris already allows you to send 2MB of write data in a single RPC request, and the RPC engine has for some time allowed you to tune the number of simultaneous RPC requests you have on the wire: Chuck has already shown that read/write performance is greatly improved by upping that value to 64 or more in the case of RPC over TCP. Why are we then suddenly telling people that they are limited to 8 simultaneous writes?
Trond
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |