Messages in this thread | | | Date | Wed, 20 May 2009 19:15:23 -0700 | Subject | Re: [PATCH 0/3] tracepoints: delay argument evaluation | From | Jiaying Zhang <> |
| |
But if we convert blktrace to use event tracer interface, we can have:
trace_block_bio_complete(md, bio);
TRACE_EVENT(block_bio_complete, TP_PROTO(struct mapped_device *md, struct bio *bio), ... TP_fast_assign( __entry->queue = md->queue; ... ), );
Jiaying
On Wed, May 20, 2009 at 6:59 PM, Li Zefan <lizf@cn.fujitsu.com> wrote: > Jiaying Zhang wrote: >> Is it possible to convert blktrace to use event tracer? Then in this case we > > Yes, I'm doing this, see: > http://marc.info/?l=linux-kernel&m=124228198011297&w=2 > >> can pass 'md' as the parameter to trace_block_bio_complete and dereference >> md->queue during assignment. >> > > But the problem discussed here exists whether you use plain tracepoints > or TRACE_EVENT. > > Though we can add a new tracepoint named trace_md_bio_complete, this is > not the way to solve it. > >> Jiaying >> >> On Wed, May 20, 2009 at 8:42 AM, Jason Baron <jbaron@redhat.com> wrote: >>> On Wed, May 20, 2009 at 09:33:48AM +0200, Ingo Molnar wrote: >>>> hm, this is really a compiler bug in essence - the compiler should >>>> delay the construction of arguments into unlikely branches - if the >>>> arguments are only used there. >>>> >>>> We'd basically open-code a clear-cut: >>>> >>>> trace_block_bio_complete(md->queue, bio); >>>> >>>> into this form: >>>> >>>> trace(block_bio_complete, md->queue, bio); >>>> >>>> .. and this latter form could become moot (and a nuisance) if the >>>> compiler is fixed. >>>> >>>> Have you tried very latest GCC, does it still have this optimization >>>> problem? >>>> >>>> Note that the compiler getting this right would help a _lot_ of >>>> other inline functions in the kernel as well. Arguments only used >>>> within unlikely() branches are quite common. >>>> >>>> Ingo >>> hi, >>> >>> I e-mailed the gcc list, where they suggested using a macro, as I've >>> done. They also suggested filing an enhancement request for this, which >>> I've done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40207 It seems >>> like they agree with the suggestion. >>> >>> It still might make sense to make this requirement explicit (by adding >>> the extra macro), as the tracepoint off case should really be as optimized as >>> possible. >>> >>> thanks, >>> >>> -Jason >>> >
| |