* Jiri Olsa <jolsa@xxxxxxxxxx> [2012-01-16 16:33:27]: > On Mon, Jan 16, 2012 at 08:15:38PM +0530, Srikar Dronamraju wrote: > > > > > > I've tested following event: > > > echo "p:probe_libc/free /lib64/libc-2.13.so:0x7a4f0 %ax" > ./uprobe_events > > > > > > and commands like: > > > perf record -a -e probe_libc:free --filter "common_pid == 1127" > > > perf record -e probe_libc:free --filter "arg1 == 0xa" ls > > > > > > got me proper results. > > > > > > > Okay thanks for the inputs. > > > > > thanks, > > > jirka > > > > > > --- > > > The preemption needs to be disabled when submitting data into perf. > > > > I actually looked at other places where perf_trace_buf_prepare and > > perf_trace_buf_submit are being called. for example perf_syscall_enter > > and perf_syscall_exit both call the above routines and they didnt seem > > to be called with premption disabled. Is that the way perf probe is > > called in our case that needs us to call pre-emption here? Did you see a > > case where calling these without preemption disabled caused a problem? > > the perf_trace_buf_prepare touches per cpu variables, > hence the preemption disabling > > the perf_trace_buf_prepare code is used by syscalls, > kprobes, and trace events > > - both syscalls and trace events are implemented by > tracepoints which disable preemption before calling the probe > (see __DO_TRACE macro in include/linux/tracepoint.h) > > - kprobes disable preemption as well > (kprobe_handler in arch/x86/kernel/kprobes.c) > haven't checked the optimalized kprobes, > but should be the same case > > jirka > Okay, thanks for the clarification, I will pick the fix. -- Thanks and Regards Srikar -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>