From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 10:24:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DC3516A420; Fri, 28 Oct 2005 10:24:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B83AA43D45; Fri, 28 Oct 2005 10:24:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 414F746BB1; Fri, 28 Oct 2005 06:24:18 -0400 (EDT) Date: Fri, 28 Oct 2005 11:24:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Vaibhave Agarwal In-Reply-To: Message-ID: <20051028105057.J20147@fledge.watson.org> References: <20051027233636.GA39380@dmw.hopto.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd , freebsd Subject: Re: how to make the FreeBSD 6.0 run faster X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 10:24:19 -0000 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