Messages in this thread | | | Date | Wed, 30 Mar 2005 16:20:56 +0200 | From | Ingo Molnar <> | Subject | Re: NFS client latencies |
| |
* Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> > the comment suggests that this is optimized for append writes (which is > > quite common, but by far not the only write workload) - but the > > worst-case behavior of this code is very bad. How about disabling this > > sorting altogether and benchmarking the result? Maybe it would get > > comparable coalescing (higher levels do coalesce after all), but wastly > > improved CPU utilization on the client side. (Note that the server > > itself will do sorting of any write IO anyway, if this is to hit any > > persistent storage - and if not then sorting so agressively on the > > client side makes little sense.) > > No. Coalescing on the client makes tons of sense. The overhead of > sending 8 RPC requests for 4k writes instead of sending 1 RPC request > for a single 32k write is huge: among other things, you end up tying up > 8 RPC slots on the client + 8 nfsd threads on the server instead of just > one of each.
yes - coalescing a few pages makes sense, but linearly scanning thousands of entries is entirely pointless.
Ingo - 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/
| |