Skip site navigation (1)Skip section navigation (2)
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>