Re: [PATCH 0/3] tracepoints: delay argument evaluation

From: Jason Baron
Date: Tue May 19 2009 - 18:21:31 EST


On Tue, May 19, 2009 at 05:17:04PM -0400, Mathieu Desnoyers wrote:
> * Jason Baron (jbaron@xxxxxxxxxx) wrote:
> > hi,
> >
> > After disassembling some of the tracepoints, I've noticed that arguments that
> > are passed as macros or that perform dereferences, evaluate prior to the
> > tracepoint on/off check. This means that we are needlessly impacting the
> > off case.
> >
> > I am proposing to fix this by adding a macro that first checks for on/off and
> > then calls 'trace_##name', preserving type checking. Thus, callsites have to
> > move from:
> >
> > trace_block_bio_complete(md->queue, bio);
> >
> > to:
> >
> > tracepoint_call(block_bio_complete, md->queue, bio);
> >
>
> I knew this limitation in the first place, but decided it was not worth
> uglifying the tracepoint call site for it.

hmmm...i don't think its terribly ugly.

>
> The expected use is to pass a pointer or a value as tracepoint argument
> and dereference it in the callback attached to it.
>

there are a lot of tracepoints that pass more than just a pointer...do
we want to be slowing up i/o paths, when tracepoints are disabled?


> Is there any _real_ added value for going through this API change pain ?
>

the value is in being able to define the tracepoint api more easily to
one's liking and not have additional instructions in the off case, where
they can easily be avoided.

thanks,

-Jason



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/