Re: Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2014-06-19 Thread Masami Hiramatsu
(2014/06/19 11:28), Paul E. McKenney wrote: > On Wed, Jun 18, 2014 at 09:56:26PM -0400, Steven Rostedt wrote: >> >> Another blast from the past (from the book of cleaning out inbox) >> >> On Wed, 29 May 2013 09:52:49 +0200 >> Peter Zijlstra wrote: >> >>> On Tue, May 28, 2013 at 08:01:16PM -0400, S

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2014-06-18 Thread Paul E. McKenney
On Wed, Jun 18, 2014 at 09:56:26PM -0400, Steven Rostedt wrote: > > Another blast from the past (from the book of cleaning out inbox) > > On Wed, 29 May 2013 09:52:49 +0200 > Peter Zijlstra wrote: > > > On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote: > > > The function tracer us

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2014-06-18 Thread Steven Rostedt
Another blast from the past (from the book of cleaning out inbox) On Wed, 29 May 2013 09:52:49 +0200 Peter Zijlstra wrote: > On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote: > > The function tracer uses preempt_disable/enable_notrace() for > > synchronization between reading regi

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-06-05 Thread Steven Rostedt
On Wed, 2013-06-05 at 13:51 +0200, Peter Zijlstra wrote: > > @@ -456,9 +471,13 @@ static int __unregister_ftrace_function( > > /* > > * Dynamic ops may be freed, we must make sure that all > > * callers are done before leaving this function. > > +* > > +* Again, normal synchr

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-06-05 Thread Peter Zijlstra
On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote: > The function tracer uses preempt_disable/enable_notrace() for > synchronization between reading registered ftrace_ops and unregistering > them. > > Most of the ftrace_ops are global permanent structures that do not > require this sy

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-06-04 Thread Frederic Weisbecker
On Tue, Jun 04, 2013 at 08:11:21AM -0400, Steven Rostedt wrote: > On Tue, 2013-06-04 at 13:03 +0200, Frederic Weisbecker wrote: > > > If ftrace were to use rcu_dereference_sched() instead of > > rcu_dereference_raw(), I guess > > the issue would have been detected before. But I guess we want to a

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-06-04 Thread Steven Rostedt
On Tue, 2013-06-04 at 13:03 +0200, Frederic Weisbecker wrote: > If ftrace were to use rcu_dereference_sched() instead of > rcu_dereference_raw(), I guess > the issue would have been detected before. But I guess we want to avoid that > for > tracing recursion? It's been detected before, just ign

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-06-04 Thread Frederic Weisbecker
On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote: > The function tracer uses preempt_disable/enable_notrace() for > synchronization between reading registered ftrace_ops and unregistering > them. > > Most of the ftrace_ops are global permanent structures that do not > require this sy

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-05-29 Thread Steven Rostedt
On Wed, 2013-05-29 at 06:33 -0700, Paul E. McKenney wrote: > > Is there something a little smarter we can do? Could we use > > on_each_cpu_cond() with a function that checks if the CPU really is > > fully idle? > > One recent change that should help is making the _rcuidle variants of > the tracin

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-05-29 Thread Steven Rostedt
On Wed, 2013-05-29 at 09:52 +0200, Peter Zijlstra wrote: > Just to be clear, its the idle part that's a problem, right? Actually, it's the userspace part that's triggered the bugs. > Being stuck > in userspace isn't a problem since if that CPU is in userspace its > certainly not got a referenc

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-05-29 Thread Paul E. McKenney
On Wed, May 29, 2013 at 09:52:49AM +0200, Peter Zijlstra wrote: > On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote: > > The function tracer uses preempt_disable/enable_notrace() for > > synchronization between reading registered ftrace_ops and unregistering > > them. > > > > Most of

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-05-29 Thread Paul E. McKenney
On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote: > The function tracer uses preempt_disable/enable_notrace() for > synchronization between reading registered ftrace_ops and unregistering > them. > > Most of the ftrace_ops are global permanent structures that do not > require this sy

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-05-29 Thread Peter Zijlstra
On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote: > The function tracer uses preempt_disable/enable_notrace() for > synchronization between reading registered ftrace_ops and unregistering > them. > > Most of the ftrace_ops are global permanent structures that do not > require this sy

[RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

2013-05-28 Thread Steven Rostedt
The function tracer uses preempt_disable/enable_notrace() for synchronization between reading registered ftrace_ops and unregistering them. Most of the ftrace_ops are global permanent structures that do not require this synchronization. That is, ops may be added and removed from the hlist but are