Re: [PATCH tracing/kprobes 4/7] tracing/kprobes: Add event profilingsupport

From: Masami Hiramatsu
Date: Mon Sep 14 2009 - 12:51:34 EST




Frederic Weisbecker wrote:
On Fri, Sep 11, 2009 at 12:22:16PM -0400, Masami Hiramatsu wrote:
Frederic Weisbecker wrote:
+static int probe_profile_enable(struct ftrace_event_call *call)
+{
+ struct trace_probe *tp = (struct trace_probe *)call->data;
+
+ if (atomic_inc_return(&call->profile_count))
+ return 0;
+
+ if (probe_is_return(tp)) {
+ tp->rp.handler = kretprobe_profile_func;
+ return enable_kretprobe(&tp->rp);
+ } else {
+ tp->rp.kp.pre_handler = kprobe_profile_func;
+ return enable_kprobe(&tp->rp.kp);
+ }
+}



May be I misunderstood but it seems that concurrent uses of
ftrace and perf would really mess up the result, as one would
overwrite the handler of the other.

Even though it's hard to imagine one using both at the same
time on the same probe, but still...

Oops, it's my misunderstanding. I thought those are exclusively
enabled each other.


It's automatically managed with events because ftrace and
and perf have their individual tracepoint probes, because
tracepoints support multiple probes.


Is it possible to have two kprobes having the exact same
properties? (pointing to the same address, having the same
probe handlers, etc...)

Another solution would be to allow kprobes to have multiple
handlers.

It could be to have multiple kprobes on same point, but I think
it's waste of the memory and time in this case.


Yeah.



I'd like to have a dispatcher function and flags internally :)


You mean kprobes that could support multiple probes?
That would be a nice solution IMHO...

Yeah, actually kprobes could support multiple probes on the
same point. But kprobe structure has many extensions which
kprobe-tracer doesn't need, e.g. post_handler/break_handler,
opcode, arch sprcific instructions.
Kretprobe consumes more memories for storing return points :(.

Thus, if we know there are two functions to be called on the
same probe point, I think it is better to have a dispatcher.
(Especially, in this case, we can call fixed functions, so
it's easier way.)

Thank you,

--
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division

e-mail: mhiramat@xxxxxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/