Re: [PATCH] tracing: Cleanup the convoluted softirq tracepoints

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

* Thomas Gleixner (tglx@linutronix.de) wrote:
> On Tue, 19 Oct 2010, Steven Rostedt wrote:
> 
> > On Tue, 2010-10-19 at 15:41 +0200, Thomas Gleixner wrote:
> > > On Tue, 19 Oct 2010, Mathieu Desnoyers wrote:
> > 
> > > Dudes, a vector computation is hardly a performance problem in that
> > > function and definitely not an excuse for designing such horrible
> > > interfaces.
> > 
> > Yes, now we can be a bit more liberal. But when these tracepoints were
> > going in, people were watching to make sure they have practically zero
> > impact when tracing was disabled.
> > 
> > Now that people are more use to tracepoints, they are more understanding
> > to have cleaner code over that extra few more lines of machine code in
> > the fast path.
> 
> The vector computation is compared to the extra tracing induced jumps
> probably not even measurable. Stop defending horrible coding with
> handwavy performance and impact arguments.

>From the moment markers and tracepoints infrastructures were merged, the
performance overhead target has been assuming we would eventually be merging
"asm goto jump labels", which replace the load+test+branch with a no-op.

So compared to a 5 bytes no-op added to the fast path, this vector computation
can be expected to have a higher performance impact, because skipping a no-op on
modern architectures (x86 at least) adds technically zero cycles. Agreed, there
is still the impact on I$, extra register pressure, some leaf functions becoming
non-leaf, and added function call (which imply external side-effect, thus acting
like a barrier()). But saying that all we do is to provide handwavy performance
and impact arguments is a bit much.

Until the asm goto are more widely deployed and until gcc 4.5 is more widely
used, there are some instrumentation sites I am relunctant to consider to
instrument with tracepoints (e.g. all system call entry/exit sites). However,
we should not use the cost of the current load+test+branch tracepoint behavior
as an excuse for adding extra performance impact to kernel code, because when it
will be replaced by asm gotos, all that will be left is the performance impact
inappropriately justified as insignificant compared to the impact of the old
tracepoint scheme.

Thanks,

Mathieu

> 
> Thanks,
> 
> 	tglx

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com