Messages in this thread | | | Subject | Re: [PATCH 1/3] x86/sched/context_tracking: Call new schedule_preempt_user() from entry_64.S | From | Steven Rostedt <> | Date | Mon, 13 May 2013 11:03:39 -0400 |
| |
On Mon, 2013-05-13 at 17:56 +0800, Li Zhong wrote:
> > All this before schedule_user() was able to call user_exit() and take us > > out of dynamic tick user context. > > Maybe we could just disable function trace for schedule_user()? > > It seems that function trace might use RCU, at least in __schedule() > when calling preempt_enable(), and if preemption is really enabled.
There is a small use of rcu scheduling (preempt disable/enable) in function tracing. One is for perf and dynamic call traces and some hash code (multiple users of the function tracer). But those are the unique cases, and I really do not want to remove this function just for the non common case. Function tracing has proven extremely useful in debugging RCU and context tracking. By adding notrace, it's a lost cause.
Not to mention, adding trace_printk() there will break it too, and that does not use any RCU but still disables preemption because the writing to the ring buffer requires staying on the same CPU.
> > user_exit() is used to allow RCU usage after that (with rcu_user_exit). > RCU usage is not allowed before that because cpu is in user eqs. And if > function trace needs use RCU, then it seems user_exit() itself or its > callers couldn't be function traced.
And it can't be debugged either.
I can probably black list those functions manually, such that only the main function tracer can trace it, all others will not. In otherwords, I can have it such that function tracer will not trace those functions for perf, dynamic function tracers, or anything that requires changing the function list.
I could probably also add a heavier weight synchronize_sched() that even synchronizes cpus in userspace.
> > If __schedule() in preempt_enable() is the only place function trace > uses RCU, then after converting to schedule_preempt_user(), it is safe > as irqs are disabled for __schedule() to happen. But user_exit() itself > and some other callers might still need function trace be disabled.
The above makes no sense to me. function tracing didn't break, but the user_exit() did because of a preemption in the wrong place, as there was no protection there to prevent an unnecessary preemption.
-- Steve
| |