From owner-freebsd-current Sun Aug 22 8:26:22 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 1225C1516F; Sun, 22 Aug 1999 08:26:18 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id QAA91151; Sun, 22 Aug 1999 16:34:42 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Sun, 22 Aug 1999 16:34:42 +0100 (BST) From: Doug Rabson To: Matthew Dillon Cc: "John S. Dyson" , Alfred Perlstein , Eivind Eklund , Peter Wemm , current@freebsd.org Subject: Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h) In-Reply-To: <199908211649.JAA73759@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 21 Aug 1999, Matthew Dillon wrote: > :> Well, the issue with converting many of the macros to inline functions > :> is with the embedded goto's and references to variables defined outside > :> the macros. Converting them to functions would basically require > :> rewriting a huge chunk of NFS code. > :> > :My working kernel runs with a few strategic NFS macros being converted > :to functions, and the size improvement is about 50K or so (maybe more!!!) > : > :John > > If you want to port some of it in that part of the source tree will be > available in a month or two, depending on how quickly the other stuff in > my queue gets committed. I've got two patch sets currently under test > related to other NFS issues and a third one in the wings. > > Hey, speaking of NFS ... I'm working on optimizing the commit rpc and > I noticed something interesting. The commit rpc includes an offset and > a length field. > > Does anyone know why our NFS clients are sending a separate RPC for each > 8K buffer? If the dirty space is contiguous across a number of buffers > we should be able to send a *SINGLE* commit rpc to the server. That would > greatly reduce system overhead on both the client and server when writing > a large file over NFS. This would seem to be an almost free optimization > that would mesh extremely well with the nfsrv_commit optimizations I'm > making right now. > > At the moment I can saturate a 100BaseTX with NFS writes and get > 10 MBytes/sec to the platter on the server, but the cpu required on both > the client and server to do that is well over 60% of a Pentium III-450. I worked on reducing the number of commit rpcs a while ago. The best I could come up with was to use the B_CLUSTEROK flag to get vfs_bio.c to aggregate several buffers together to make a single large commit. Does that code still work? It made a big difference to the number of commit rpcs at the time. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message