Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: trost@cloud.rain.com (Bill Trost)
Subject: [lttng-dev] using --function/--probe
Date: Wed, 06 Jun 2012 07:48:17 -0700	[thread overview]
Message-ID: <19046.1338994097@cloud.rain.com> (raw)
In-Reply-To: Your message of Tue, 05 Jun 2012 11:49:50 EDT. <20120605154950.GA21955@Krystal>

Mathieu wrote:
    * Bill Trost (trost at cloud.rain.com) wrote:
    > and how does it differ from "--probe"? How do I determine
    > what symbols are valid for each of these options?

    It entirely depends on which functions are blacklisted in the kernel
    (this is an attribute added to the functions specifically for kprobes).
    The keyword is "__kprobes".

Is that the only basis? For example, I can add a dynamic tracepoint (of
either flawor) for queue_work_on(), but not work __queue_work(), yet
neither of those functions have any apparent annotation. Or does
EXPORT_SYMBOL_GPL imply a probe point?

    > ...how do I trace what work is being
    > enqueued and run by the kworker threads?

    For this level of details, I think kprobes/kretprobes will not
    currently allow you to fetch it. The two options we have are:

    - use static tracepoints. Is there a tracepoint that targets the
      information you are looking for ? Try "lttng list -k".

No, I've been capturing all kernel events and haven't seen
anything resembling the kworker tracepoints of lttng 0.x.

    - or extend the dynamic probing to allow fetching variables from
      debug information,

Hmm. Well, I did a bit more poking and got a bit closer -- at least now
I know what dynamic points to use. (eg, "queue_work_on" and friends to
see what is being queued). I take it that LTT can't capture function call
arguments as a form of additional context? That would be an ideal
bit of information in this case.

Thanks again,
Bill



      parent reply	other threads:[~2012-06-06 14:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-02 14:35 Bill Trost
2012-06-05 15:49 ` Mathieu Desnoyers
2012-06-06 14:48 ` Bill Trost [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=19046.1338994097@cloud.rain.com \
    --to=trost@cloud.rain.com \
    /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