* Jyotiswarup Raiturkar ([email protected]) wrote:
> Ok I think I'm beginning to understand the scheme. For a tracepoint like
> irq_exit, DECLARE_MARKER_TP() defines an corresponding marker. And when
> set_marker() is called, the probe callback mentioned in
> DEFINE_MARKER_TP() gets attached to the tracepoint. The tracepoint
> itself is hit when the trace_* (trace_irq_exit) is called by the
> module/subsystem performing the trace. Is this understanding correct?

Yes.

> 
> Couple of more questions though:
> - Why is this better/"optimized" instead of just calling
> register_trace_* (register_trace_irq_exit )?

see ltt-serialize.c which provides a "generic" serializer. But it's
slower. The "custom" serializer require that the programmer write code
for each event, hence the "specialized". Note that I will replace all
this by TRACE_EVENT() eventually.

> - set_marker() is called by marker_update_probe_range() which is called
> when probe functions are registered/unregistered, and modules are
> loaded/unloaded. But you said below that this is called when markers are
> 'enabled'. Does registering a probe function, enable a marker?

Yes.

> 
> I'm trying to attach custom probes, to the kernel markers and
> tracepoints; hence all the questions.

No problem. I'm glad to help you clarify this.

Thanks,

Mathieu

> 
> Thanks
> Jyotiswarup
> 
> -----Original Message-----
> From: Mathieu Desnoyers [mailto:[email protected]] 
> Sent: Thursday, May 20, 2010 7:34 PM
> To: Jyotiswarup Raiturkar
> Cc: [email protected]
> Subject: Re: [ltt-dev] LLTng probes
> 
> probe_irq_exit is the callback that the tracepoint will call.
> 
> So we have, at the moment, for "optimized probes" (written by hand, not
> serialized dynamically):
> 
> tracepoint -> probe_irq_exit -> ltt_specialized_trace()
> 
> These "optimized probes" skip the marker code entirely. They are only
> tied to markers for the event type definitions.
> 
> Thanks,
> 
> Mathieu
> 
> 
> * Jyotiswarup Raiturkar ([email protected]) wrote:
> > >> The probes are connected to the tracepoints with: kernel:marker.c:
> > set_marker()
> > 
> > Actually my question was where is the actual trace out call made? For
> > example for the tracepoint defined by DEFINE_TRACE(irq_exit), the
> trace
> > out call is trace_irq_exit(). Similarly there is a trace marker called
> > DEFINE_MARKER_TP() for irq_exit :
> > Kernel-trace.c : 
> >     DEFINE_MARKER_TP(kernel, irq_exit, irq_exit, probe_irq_exit,
> > "handled #1u%u");
> > 
> > But I don't see how this marker is actually hit during execution. What
> > is the call similar to trace_irq_exit() for the Tracepoint?
> > 
> > Thanks
> > Jyotiswarup Raiturkar
> > 
> > -----Original Message-----
> > From: Mathieu Desnoyers [mailto:[email protected]] 
> > Sent: Wednesday, May 19, 2010 8:00 PM
> > To: Jyotiswarup Raiturkar
> > Cc: [email protected]
> > Subject: Re: [ltt-dev] LLTng probes
> > 
> > * Jyotiswarup Raiturkar ([email protected]) wrote:
> > > Hello
> > > 
> > >  
> > > 
> > > I'm looking at LTTng working inside the kernel, and trying to
> > understand
> > > the instrumentation.
> > > 
> > >  
> > > 
> > > However, I am not able to see how the DEFINE_MARKER_TP() macros and
> > > other probe_* functions in kernel-trace.c are actually used . As I
> > > understand it, to make the actual trace, modules would have to call
> > the
> > > probe_* functions; yet I'm not able to locate these calls.
> > 
> > The probes are connected to the tracepoints with:
> > 
> > kernel:marker.c: set_marker()
> > 
> >                      ret = tracepoint_probe_register_noupdate(
> >                                 elem->tp_name,
> >                                 elem->tp_cb);
> > 
> > Which is called when a marker is enabled. The markers are listed in a
> > table which is defined by the DEFINE_MARKER_TP() macros.
> > 
> > Thanks,
> > 
> > Mathieu
> > 
> > > 
> > >  
> > > 
> > > Thanks
> > > 
> > > Jyoti
> > > 
> > > -- 
> > > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> > recipient, please notify the sender immediately and do not disclose
> the
> > contents to any other person, use it for any purpose, or store or copy
> > the information in any medium.  Thank you.
> > 
> > > _______________________________________________
> > > ltt-dev mailing list
> > > [email protected]
> > > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> > 
> > 
> > -- 
> > Mathieu Desnoyers
> > Operating System Efficiency R&D Consultant
> > EfficiOS Inc.
> > http://www.efficios.com
> > -- 
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy
> the information in any medium.  Thank you.
> > 
> 
> -- 
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com
> -- 
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium.  Thank you.
> 

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

_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

Reply via email to