On Wed, 2005-03-30 at 16:14 -0500, Trond Myklebust wrote: > on den 30.03.2005 Klokka 11:56 (-0800) skreiv Andrew Morton: > > > That's normal and cannot be avoided: when writing, we have to look for > > > the existence of old nfs_page requests. The reason is that if one does > > > exist, we must either coalesce our new dirty area into it or if we > > > can't, we must flush the old request out to the server. > > > > One could use the radix-tree tagging stuff so that the gang lookup only > > looks up pages which are !NFS_WBACK_BUSY. > > Yes. Together with the radix tree-based sorting of dirty requests, > that's pretty much what I've spent most of today doing. Lee, could you > see how the attached combined patch changes your latency numbers? > Different code path, and the latency is worse. See the attached ~7ms trace. Lee
Attachment:
nfs-6776usec-trace.bz2
Description: application/bzip
- Follow-Ups:
- Re: NFS client latencies
- From: Ingo Molnar <[email protected]>
- Re: NFS client latencies
- From: Andrew Morton <[email protected]>
- Re: NFS client latencies
- References:
- NFS client latencies
- From: Lee Revell <[email protected]>
- Re: NFS client latencies
- From: Trond Myklebust <[email protected]>
- Re: NFS client latencies
- From: Lee Revell <[email protected]>
- Re: NFS client latencies
- From: Trond Myklebust <[email protected]>
- Re: NFS client latencies
- From: Andrew Morton <[email protected]>
- Re: NFS client latencies
- From: Trond Myklebust <[email protected]>
- NFS client latencies
- Prev by Date: Re: [RFC] CryptoAPI & Compression
- Next by Date: Re: Directory link count wrapping on Linux/XFS/i386?
- Previous by thread: Re: NFS client latencies
- Next by thread: Re: NFS client latencies
- Index(es):