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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
