On Thu, 2006-02-02 at 18:48, Andi Kleen wrote: > On Thursday 02 February 2006 08:31, Greg Banks wrote: > > > [...]SGI's solution is do is ship a script that uses ethtool > > at boot to tune rx-usecs, rx-frames, rx-usecs-irq, rx-frames-irq > > up from the defaults. > > All user tuning like this is bad. The stack should all do that automatically.
That would be nice ;-) > Would there be a drawback of making these > settings default? Yes, as mentioned elsewhere in this thread, applications which are latency-sensitive will suffer. For example, SGI sells a clustered filesystem where overall performance is sensitive to the RTT of intra-cluster RPCs, to which receive latency due to NIC interrupt mitigation is a significant factor. The NICs which run that traffic need to be using minimum mitigation, but the NICs which run NFS traffic need to be using maximum mitigation. > > This helps a lot, and we're very grateful ;-) But a scheme > > which used the interrupt mitigation hardware dynamically based on > > load could reduce the irq rate and CPU usage even further without > > compromising latency at low load. > > If you know what's needed perhaps you could investigate it? Maybe, in a couple of months when I've the time. > You mean the 64k limit? Exactly. Currently the NFS server is limited to a 32K blocksize so the largest RPC reply size is about 33K. However the NFS client in Linus' tree, and other OS's NFS servers, have much larger limits. A value of about 1.001 MiB would probably be best. The next SGI Linux NFS server release will probably include a patch to increase the maximum blocksize on TCP to 1MiB. > > Cool. Wouldn't it mean rewriting the nontrivial qdiscs? > > It had some compat code that just split up the lists - same > for netfilter. And only an implementation for pfifo_fast. Ok by me, in practice our servers only ever use pfifo. > (Don't ask for code - it's not really in an usable state) Sure. I'm looking forward to it. Greg. -- Greg Banks, R&D Software Engineer, SGI Australian Software Group. I don't speak for SGI. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
