Re: ftrace multibuffer && rcu (Was: tracing/uprobes: Support ftrace_event_file base multibuffer)

2013-06-14 Thread Oleg Nesterov
On 06/14, Steven Rostedt wrote: > > On Fri, 2013-06-14 at 18:04 +0200, Oleg Nesterov wrote: > > > > But the main problem is, synchronize_sched() is slow and it is called > > under the global event_mutex. > > But is that really an issue? event_mutex is used to add or remove > events, and this happen

Re: ftrace multibuffer && rcu (Was: tracing/uprobes: Support ftrace_event_file base multibuffer)

2013-06-14 Thread Steven Rostedt
On Fri, 2013-06-14 at 18:04 +0200, Oleg Nesterov wrote: > On 06/14, Oleg Nesterov wrote: > > > > > -probe_event_enable(struct trace_uprobe *tu, int flag, filter_func_t > > > filter) > > > +probe_event_enable(struct trace_uprobe *tu, struct ftrace_event_file > > > *file, > > > +filter_

Re: ftrace multibuffer && rcu (Was: tracing/uprobes: Support ftrace_event_file base multibuffer)

2013-06-14 Thread Oleg Nesterov
On 06/14, Oleg Nesterov wrote: > > So perhaps something like below (untested) makes sense? With this patch > we can trivially convert trace_kprobe.c to use list_add/del/each_rcu. Forgot to mention, the patch is obviously incomplete, __kprobe_trace_func() can see the "dead" file even if its memory

ftrace multibuffer && rcu (Was: tracing/uprobes: Support ftrace_event_file base multibuffer)

2013-06-14 Thread Oleg Nesterov
On 06/14, Oleg Nesterov wrote: > > > -probe_event_enable(struct trace_uprobe *tu, int flag, filter_func_t filter) > > +probe_event_enable(struct trace_uprobe *tu, struct ftrace_event_file *file, > > + filter_func_t filter) > > { > > + int enabled = 0; > > int ret = 0; > > > > +