lkml.org 
[lkml]   [2005]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-04-06 13:31    [W:0.083 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site