Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Subject: [ltt-dev] LLTng probes
Date: Fri, 21 May 2010 08:23:59 -0400	[thread overview]
Message-ID: <20100521122359.GC27410@Krystal> (raw)
In-Reply-To: <34F012EAAD78FB49A2AFF01BF6DCE07602A4AC59@ASHWA.Asiapac.Arm.com>

* Jyotiswarup Raiturkar (Jyotiswarup.Raiturkar at arm.com) 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:compudj@krystal.dyndns.org] 
> Sent: Thursday, May 20, 2010 7:34 PM
> To: Jyotiswarup Raiturkar
> Cc: ltt-dev at lists.casi.polymtl.ca
> 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 (Jyotiswarup.Raiturkar at arm.com) 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:compudj@krystal.dyndns.org] 
> > Sent: Wednesday, May 19, 2010 8:00 PM
> > To: Jyotiswarup Raiturkar
> > Cc: ltt-dev at lists.casi.polymtl.ca
> > Subject: Re: [ltt-dev] LLTng probes
> > 
> > * Jyotiswarup Raiturkar (Jyotiswarup.Raiturkar at arm.com) 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
> > > ltt-dev at lists.casi.polymtl.ca
> > > 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




      reply	other threads:[~2010-05-21 12:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19  8:49 Jyotiswarup Raiturkar
2010-05-19  8:49 ` Jyotiswarup Raiturkar
2010-05-19  8:49 ` Jyotiswarup Raiturkar
2010-05-19 14:30 ` Mathieu Desnoyers
2010-05-20 11:10   ` Jyotiswarup Raiturkar
2010-05-20 14:03     ` Mathieu Desnoyers
2010-05-20 21:50       ` [ltt-dev] LTT UserSpace Tracer, broken? jpaul
2010-05-20 23:08         ` Mathieu Desnoyers
2010-05-21 18:49         ` Pierre-Marc Fournier
2010-05-24 17:11           ` jpaul
2010-05-28 16:51             ` Pierre-Marc Fournier
     [not found]               ` <A47866F933DF804684068A24BF04A9730862A874@gdrs-exchange.gdrs.com>
     [not found]                 ` <A47866F933DF804684068A24BF04A9730862A878@gdrs-exchange.gdrs.com>
2010-06-19 16:01                   ` Mathieu Desnoyers
2010-05-21  6:43       ` [ltt-dev] LLTng probes Jyotiswarup Raiturkar
2010-05-21 12:23         ` Mathieu Desnoyers [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100521122359.GC27410@Krystal \
    --to=compudj@krystal.dyndns.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox