Date: Fri, 28 Oct 2005 11:24:18 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Vaibhave Agarwal <vaibhave@cs.utah.edu> Cc: freebsd <freebsd-net@freebsd.org>, freebsd <freebsd-hackers@freebsd.org> Subject: Re: how to make the FreeBSD 6.0 run faster Message-ID: <20051028105057.J20147@fledge.watson.org> In-Reply-To: <Pine.LNX.4.61.0510271744100.19263@trust.cs.utah.edu> References: <20051027233636.GA39380@dmw.hopto.org> <Pine.LNX.4.61.0510271744100.19263@trust.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Oct 2005, Vaibhave Agarwal wrote: > How do u disable malloc debugging flags in the userland? I read > somewhere that " ln -s aj /etc/malloc.conf" disables malloc debugging. > How does it work? > > And how to disable verbose features in the kernel? > > Apart from this, are there other ways to make the kernel run faster?? The note has now been removed, since it was accurate only through the beta series. "Run faster" is a bit nebulous, as performance optimization is a complex thing. Since you CC'd the net@ list, I assume you want the networking to run faster. The usual techniques are: - If your workload permits it, run with network stack direct dispatch, which avoids a context switch into the network stack. Be warned that this may reduce the opportunities for parallelism between the interrupt and link layer code and network layer code, so while it improves many workloads, it won't improve all. Set net.dispatch.direct=1. - If your workload benefits from it, consider running with device polling -- this moves form an interrupt driven network model to a polled network model, greatly decreasing overhead as a result of avoiding thrashing interrupt handlers, and allowing you to moderate the load generated by the network. See polling(4) for details, as this requires a custom kernel configuration and some careful thought. This is usually best for routers, etc. Polling may increase the latency of packet processing based on how frequently polling polls, but substantially increase throughput. - Depending on the workload and hardware, you may want to reconsider compiling with SMP. I.e., for some workloads, HTT helps, and SMP helps, and for other workloads, it doesn't. - Carefully evaluate your hardware configuration -- if this is about network performance, you may want to make sure that storage and networking devices are on separate PCI buses, and that if needed, those buses are 64-bit. - Another common hardware issue is shared interrupts -- for example, on many motherboards, USB and the on-motherboard network device end up on the same interrupt, or their interrupts fire simultaneously regardless of the interrupt numbers. Since the USB code is pretty heavy-weight, you don't want to run it every time you receive a batch of packets via an interrupt for gig-e. Compiling out USB in this environment may help. This problem can be detected using vmstat -i, and seeing if the interrupt rates for USB and your motherboard network device both look the same -- i.e., very big. - Another common concern with threaded network applications is whether the thread library model and implementation match the requirements of your application. FreeBSD provides several thread libraries with different properties, so you might want to consider changing thread libraries. - Recent reports indicate that on some systems, slow time counters are used during context switches. You may want to consider switching to a faster time counter if time accuracy is less important to you. In one measurement, this added 30% performance to loop-back network traffic. This issue is being actively researched. Other than that, you'll need to tell us what you're doing. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051028105057.J20147>