On Fri, Apr 22, 2011 at 7:29 AM, Francis Moreau <[email protected]> wrote: > On Fri, Apr 22, 2011 at 2:47 AM, David Ahern <[email protected]> wrote: >> On 04/21/11 14:07, Francis Moreau wrote: >>> On Thu, Apr 21, 2011 at 9:49 PM, David Ahern <[email protected]> wrote: >>>> >>>> You want the individual samples? if so, perf script dumps them and you >>>> can see the callchain for each sys_read. >>>> >>> >>> hmm, I don't see what you mean by individual samples. >>> >>> I don't think sampling can help in my case (tracing the callchain of >>> one syscall). >>> >>> Could you give me an example of what you have in mind ? >>> >>> Thanks >> >> I think I get it now. 'perf record' for syscall event stops at sys_read >> as that is the point the event is generated. You want where the kernel >> goes starting with sys_read. In that case you are limited to the >> pre-existing tracepoints (see 'perf list -e tracepoints') to trigger an >> event and back trace, or if the read causes the processes to block you >> can you use the context-switch event or sched_switch trace point. >> >> You could also insert probe points using perf probe. Lin Ming posted an >> example of this a couple of weeks ago: >> # ./perf probe -k ~/vmlinux -s ~/linux-2.6/ find_get_page >> # ./perf record -e probe:find_get_page -f -g -a >> > > Thanks for you answer. > > I think I'll use probe.
Thinking more about it, I think that both solution (probe or tracepoint) are not adapted. Because I'm interested in discovering the path taken by the kernel from a given syscall, therefore I don't know this path. However both solution imply that the path is known since you need to insert some 'probes' in this path to see it... -- Francis -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
