Messages in this thread |  | | | Subject | Re: [RFC PATCH 03/10] ftrace: Drop the ftrace_profile_enabled checks in tracing hot path | | From | Steven Rostedt <> | | Date | Thu, 21 Jan 2010 22:12:58 -0500 |
| |
On Thu, 2010-01-21 at 21:28 -0500, Mathieu Desnoyers wrote: > * Steven Rostedt (rostedt@goodmis.org) wrote:
> > Now for the reason I Cc'd Paul and Mathieu... > > > > If we had a synchronize_sched() like function that would wait and return > > when all preempted tasks have been scheduled again and went to either > > userspace or called schedule directly, then we could actually do this. > > > > After unregistering the function graph trace, you call this > > "synchronize_tasks()" and it will guarantee that all currently preempted > > tasks have either went to userspace or have called schedule() directly. > > Then it would be safe to remove this check. > > OK, so basically you need to know when you reach a quiescent state, but > preemption is enabled and there is no RCU read lock taken around these > code paths, am I correct ? > > With tracepoints, life is easy because I disable preemption around the > calls, so I can use synchronize_sched() to know when quiescent state is > reached. > > I recommend looking at kernel/kprobes.c:check_safety(). It uses > thaw_processes() and synchronize_sched() for this purpose. Basically, it > rely on the "refrigeration" points to detect such quiescent state. This > trick should do the job for the function graph tracer too. > > I'm adding Masami in CC. He is the one who implemented check_safety(), > and I remember discussing it with him in the past.
Hmm, interesting. Maybe something like that might work. But what if CONFIG_PREEMPT is enabled but CONFIG_FREEZER is not?
-- Steve
|  |