On Tue, Feb 19, 2008 at 10:01:12AM +1100, David Chinner wrote:
> Now that the ktrace_enter() code is using atomics,
> the non-power-of-2 buffer sizes - which require modulus
> operations to get the index - are showing up as using
> substantial CPU in the profiles.
>
> Force the buffer sizes to be rounded up to the nearest
> power of two and use masking rather than modulus operations
> to convert the index counter to the buffer index. This
> reduces ktrace_enter overhead to 8% of a CPU time, and
> again almost halves the trace intensive test runtime.
Looks fine aswell. You might aswell kill this zentries stuff and always
use kmalloc instead of caches as the power of two multiples of
sizeof(u64) should always have matching caches available.
While we're at it the ktrace stuff should simply go away mid-term
with all the tracing stuff in mainline now. As a start all macros
calling into ktrace should become markers which allow always bulding
them in with almost zero overhead (a single no-op instruction at their
callsite) and allowing to load the actual tracing module later. As
a second step ktrace should be replaced with something based on the
various trace thingies floating around allowing to read out the trace
buffer from userspace instead of having to rely on kdb.
|