(2013/04/10 23:58), Oleg Nesterov wrote: > On 04/08, Masami Hiramatsu wrote: >> >> (2013/04/06 0:01), Oleg Nesterov wrote: >>> >>> Masami, perhaps you can also answer the question I asked in 0/4 >>> marc.info/?l=linux-kernel&m=136458107403835 ? >>> >>> Off-topic question... Why uprobe_perf_func() passes "addr = ip" to >>> perf_trace_buf_submit() ? This just sets perf_sample_data->addr for >>> PERF_SAMPLE_ADDR, do we really need this? and we already have >>> perf_sample_data->ip initialized by perf. >>> >>> kprobe_perf_func() and kretprobe_perf_func() do the same. >>> >> >> Good catch! I guess that I might misunderstood that it was used >> for sampling execution address. It should be replaced with (u64)0, >> as perf_trace_##call() does. > > Thanks! > > How about this trivial cleanup then? If I have your ack I'll add this > patch to other pending changes.
That is good for me :) > And... Cough, another question ;) To simplify, lets discuss kprobe_perf_func() > only. Suppose that a task hits the kprobe but this task/cpu doesn't have > a counter. Can't we avoid perf_trace_buf_prepare/submit in this case? > IOW, what do you think about the change below? Hmm, I'm not so sure how frequently this happens. And, is this right way to handle that case? If so, we can do same thing also on trace_events. (perf_trace_##call in include/trace/ftrace.h) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
