Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon said: : global references across subroutine calls! I'll send Luoqi another email. : : In the case of the NFS stuff, the changes have been pretty well tested : so I think we are in the clear. : :On a somewhat similar note, what do you think about converting a lot :of the NFS macros to functions, yes i know it will be difficult, but :there is so much forced inlining it just seems like it would reduce :the codesize signifigantly and play nicer with the CPU cache. : :It would also make the code a lot more readable. : :Worthwhile exercise? : :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon said: : 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. The changes are "semi-trivial", and hope that a new kernel hacker can take a crack at it. Part of my comment however true, was meant as a tease to get more kernel people involved (helping the cause.) Anything that any of us does can be done by others, and fostering a talent search is a good thing (IMO.) I am willing to provide the info, but hope that a naiscent kernel hacker comes forward... John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon wrote: 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'd like to put in a vote to get these NFS write optimizations in the pipe ASAP. The last hurdle (seemingly) on my big project at work that I've been bugging so many of you about is the fact that FreeBSD NFS client writing to Sun NFS server is just DOG slow. I did some pretty extensive testing on this and couldn't come up with any client option twidding that made any difference, except increasing wsize to 16k, which got me about 10%, but it was still very slow. This is on a -current system from around the tenth of August. Matt, thanks for all your hard work on this, and believe me when I say it couldn't come at a better time. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
:On Thu, Aug 19, 1999 at 07:50:13AM -0700, Peter Wemm wrote:
: peter 1999/08/19 07:50:13 PDT
:
: Modified files:
: sys/nfs nfsm_subs.h xdr_subs.h
: Log:
: Convert all the nfs macros to do { blah } while (0) to ensure it
: works correctly in if/else etc. egcs had probably picked up most of the
: problems here before with "ambiguous braces" etc, but this should
: increase the robustness a bit. Based on an idea from Eivind Eklund.
:
:When I tested this, I got significant binary changes after changing
:the macros to be . Writing a couple of test programs, I was not able
:to get binary changes without actual semantic changes - the optimizer
:optimize away do { ... } while(0); just fine. I didn't have any
:testbed for NFS, which was why I didn't commit similar changes myself.
:
:Interpretation: NFS is likely to be different now than it was before
:these commits. This hopefully mean less bugs, but we might also have
:had bugs cancelling each other and 'mystery fixes' that no longer
:work. If you get strange effects in NFS in the upcoming time, you
:might try flipping this commit.
:
:I still think the change is a good and necessary one.
:
:Eivind.
The compiler optimizes differently, that's all. The same thing happened
when we fixed the macros in vm_map.h. In that case we also found a bug
in i386/include/globals.h --- the inline assembly macros are missing
the "memory" side effect specification and the code was trying to optimize
global references across subroutine calls! I'll send Luoqi another email.
In the case of the NFS stuff, the changes have been pretty well tested
so I think we are in the clear.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
On Thu, 19 Aug 1999, Matthew Dillon wrote:
:On Thu, Aug 19, 1999 at 07:50:13AM -0700, Peter Wemm wrote:
: peter 1999/08/19 07:50:13 PDT
:
: Modified files:
: sys/nfs nfsm_subs.h xdr_subs.h
: Log:
: Convert all the nfs macros to do { blah } while (0) to ensure it
: works correctly in if/else etc. egcs had probably picked up most of the
: problems here before with "ambiguous braces" etc, but this should
: increase the robustness a bit. Based on an idea from Eivind Eklund.
:
:When I tested this, I got significant binary changes after changing
:the macros to be . Writing a couple of test programs, I was not able
:to get binary changes without actual semantic changes - the optimizer
:optimize away do { ... } while(0); just fine. I didn't have any
:testbed for NFS, which was why I didn't commit similar changes myself.
:
:Interpretation: NFS is likely to be different now than it was before
:these commits. This hopefully mean less bugs, but we might also have
:had bugs cancelling each other and 'mystery fixes' that no longer
:work. If you get strange effects in NFS in the upcoming time, you
:might try flipping this commit.
:
:I still think the change is a good and necessary one.
:
:Eivind.
The compiler optimizes differently, that's all. The same thing happened
when we fixed the macros in vm_map.h. In that case we also found a bug
in i386/include/globals.h --- the inline assembly macros are missing
the "memory" side effect specification and the code was trying to optimize
global references across subroutine calls! I'll send Luoqi another email.
In the case of the NFS stuff, the changes have been pretty well tested
so I think we are in the clear.
On a somewhat similar note, what do you think about converting a lot
of the NFS macros to functions, yes i know it will be difficult, but
there is so much forced inlining it just seems like it would reduce
the codesize signifigantly and play nicer with the CPU cache.
It would also make the code a lot more readable.
Worthwhile exercise?
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
systems administrator and programmer
Wintelcom - http://www.wintelcom.net/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
: global references across subroutine calls! I'll send Luoqi another email. : : In the case of the NFS stuff, the changes have been pretty well tested : so I think we are in the clear. : :On a somewhat similar note, what do you think about converting a lot :of the NFS macros to functions, yes i know it will be difficult, but :there is so much forced inlining it just seems like it would reduce :the codesize signifigantly and play nicer with the CPU cache. : :It would also make the code a lot more readable. : :Worthwhile exercise? : :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] 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. This is one of those "If it ain't broke, don't fix it" scenarios, I'm afraid. It would take too long to redo it all (and remember, I'm the guy who usually *likes* rewriting code!). As much as I would like to make NFS more readable, it just isn't worth the effort. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS HEADS UP (was Re: cvs commit: src/sys/nfs nfsm_subs.h xdr_subs.h)
Matthew Dillon writes: :On a somewhat similar note, what do you think about converting a lot :of the NFS macros to functions, yes i know it will be difficult, but :there is so much forced inlining it just seems like it would reduce :the codesize signifigantly and play nicer with the CPU cache. : :It would also make the code a lot more readable. : :Worthwhile exercise? : :-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] 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. This is one of those "If it ain't broke, don't fix it" scenarios, I'm afraid. It would take too long to redo it all (and remember, I'm the guy who usually *likes* rewriting code!). As much as I would like to make NFS more readable, it just isn't worth the effort. It still might be a "worthwhile exercise", if your goal is simply to increase your understanding of the NFS code. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
