Re: NFS client latencies

[Lee Revell <rlrevell@joe-job.com>]

On Fri, 2005-04-01 at 06:30 +0200, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > > > ah - cool! This was a 100 MB writeout so having 3.7 msecs to process 
> > > > 20K+ pages is not unreasonable. To break the latency, can i just do a 
> > > > simple lock-break, via the patch below?
> > > 
> > > with this patch the worst-case latency during NFS writeout is down to 40 
> > > usecs (!).
> > > 
> > > Lee: i've uploaded the -42-05 release with this patch included - could 
> > > you test it on your (no doubt more complex than mine) NFS setup?
> > 
> > This fixes all the NFS related latency problems I was seeing.  Now the 
> > longest latency from an NFS kernel compile with "make -j64" is 391 
> > usecs in get_swap_page.
> 
> great! The latest patches (-42-08 and later) have the reworked 
> nfs_scan_list() lock-breaker, which should perform similarly.
> 
> i bet these NFS patches also improve generic NFS performance on fast 
> networks. I've attached the full patchset with all fixes and 
> improvements included - might be worth a try in -mm?

With tracing disabled on the C3 (which is the NFS server, don't ask),
the maximum latency during the same kernel compile is about 2ms.  So
tracing overhead probably doubled or tripled the latencies.

I'll try again with tracing enabled to determine whether these code
paths are related to the NFS server or not.  It's either going to be
that or the get_swap_page stuff.  But the client side is OK now.

Lee

-
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/