* Bill Trost ([email protected]) wrote: > Mathieu wrote: > * Bill Trost ([email protected]) 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?
No, it doesn't. > > > ...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. LTTng 2.2-rc has a new workqueue instrumentation. Maybe this can fit your use-case ? > > - 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. Currently it can't. (sorry for late reply) Thanks, Mathieu > > Thanks again, > Bill -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
