More kernel works: audio, benchmarks, modules
In the past few weeks, Andrew Doran has made another bunch of
changes to NetBSD's kernel area, including interrupts in NetBSD's
audio framework, benchmarks of the system, and the handling of
SMP & audio:
One area that hasn't been changed
for moving towards fine-grained kernel locking was NetBSD's audio
subsystem. As audio recording and playback is mostly done via
interrupts, and as latency in those is critical, the audio
subsystem was moved to the new interrupt handling system.
The work can be found on the ad-audiomp branch, more information
is available in Andrew's posting about the MP safe
audio framework and drivers.
Changing a system from inside out is a huge technical task.
On the way, performance measurements and tuning are needed to
make sure that the previous performance is still achieved while
getting better performance in the desired development area.
As a result,
benchmarks results from Sun's
posted, which allow comparison not only against Linux and FreeBSD, but
also between NetBSD-current and NetBSD 4.0, in order to identify if any bad
effects were added. All performance tests were made on a machine with 8
CPUs, and the areas tested cover "small" (micro) areas like various system calls. Of course this doesn't lead to a 1:1 statement on how
the systems will perform in a real-life scenario like e.g. in a
database performance test, but it still help identifying
problems and gives better hints where tuning can be done.
Another benchmark that was also made in that regard comes
from Gregory McGarry, who has published
performance measurements previously.
This time, Gregory
has run the lmbench 3.0 benchmark on
recent NetBSD and FreeBSD systems as well as a number of previous
NetBSD releases - useful for identifying performance degradation, too!
One other benchmark on dispatch latency
run was made by Andrew Doran: on a machine
that was (CPU-wise) loaded by some compile jobs, he started a
two threads on a CPU that wasn't distracted by device interrupts,
and measured how fast the scheduler reacted when one thread
woke up the other one. The resulting graph
shows that the scheduler handles the majority of requests in less than
10us - good enough for some realtime applications?
are another area that's under heavy change right now, and after
recent changes to load modules from the bootloader and the kernel,
the kernel build process was now changed
so that pre-built kernel
modules can be linked into a new kernel binary, resulting in a
non-modular kernel. Eventually, this could mean that
src/sys is built into separate modules, and that the (many) existing
kernels that are present for each individual platform -- GENERIC,
INSTALL is already gone, ALL, etc. etc. -- can be simply linked from
pre-compiled modules, without recompiling things over again for each
kernel. Of course the overal goal here is to speed up the system (and
kernel!) build time, while maintaining maximum flexibility between
modules and non-modular kernels.
With the progress in kernel modules, it is a question of time
when the new kernel module handling supercedes the existing
loadable kernel modules to such an extent that the latter will
be completely removed from the system -- at least the
was alredy proposed, but I'd prefer to
see some documentation of the new system first. We'll see
what comes first! (Documentation writers are always welcome! :-)
[Tags: benchmark, kernel, smp]