From owner-freebsd-current Sat Aug 21 9:51:56 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id B562214F64; Sat, 21 Aug 1999 09:51:54 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA73759; Sat, 21 Aug 1999 09:49:39 -0700 (PDT) (envelope-from dillon) Date: Sat, 21 Aug 1999 09:49:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199908211649.JAA73759@apollo.backplane.com> To: "John S. Dyson" Cc: bright@rush.net (Alfred Perlstein), eivind@FreeBSD.ORG (Eivind Eklund), peter@FreeBSD.ORG (Peter Wemm), current@FreeBSD.ORG Subject: Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h) References: <199908211156.GAA20231@dyson.iquest.net.> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message