On Mon, Mar 18, 2013 at 02:23:56PM -0400, Steven Rostedt wrote: > On Mon, 2013-03-18 at 09:43 -0700, Tejun Heo wrote: > > Hello, Steven. > > > > On Mon, Mar 18, 2013 at 12:30:43PM -0400, Steven Rostedt wrote: > > > If you happen to know the critical areas that require preemption to be > > > disabled for real, we can encapsulate them with: > > > > > > preempt_disable_rt(); > > > > > > preempt_enable_rt(); > > > > > > These are currently only in the -rt patch, but it annotates locations > > > that require preemption to be disabled even when -rt converts spin_locks > > > into mutexes. These obviously can not contain spin_locks() as > > > spin_locks() can block and schedule out. > > > > Making gcwq locks disable preemption would be much safer / easier, but > > if that's not desirable, anything touching gcwq->idle_list would be a > > good place to start - worker_enter_idle() and worker_leave_idle(). > > Hmmm... ignoring CPU hotplug, I think those two might just do it. > > Give it a try? How reproducible is the problem? > > > > Hmm, the issue is that a "use to be" idle thread got migrated, and is > now being woken up by another worker. What can cause an established > worker to migrate without HOTPLUG being active? It doesn't. I think it's trying to wakeup the idle_list head. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
