Re: [patch, debug, 2/2] Use power-of-2 size ktrace buffers

[David Chinner <dgc@sgi.com>]

On Thu, Feb 21, 2008 at 11:08:07PM -0500, Christoph Hellwig wrote:
> 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.

Ok, I'll cook up another patch for that and send it out.

> 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.

Sure, that could be done.

> 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.

Yeah, that make sense for tracing from userspace. But most of the
time I find a need for the tracing is when the machine has crashed
or assert failed. Hence I don't see that we can really remove the
kdb side of things. Perhaps two different tracing modules could
be done.....

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group