:> 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
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message