> > It looks to me that something either needs to wake up the idle cpu when > an rcu callback is scheduled on it (I couldnt figure out how to do > that), or it should not be scheduled on a completely idle cpu as this > cpu is already in a quiescent state.
While there are other possibilities, I'm thinking if the RCU callback softIRQ was not handed at the end of IPI handler (although to be honest, I'm not entirely sure how it's raised in the first place, as by just looking at the whole grace period handling, it's so confusing:) ? As IPIs don't fall through the normal interrupt handling logic, a proper irq_enter() and irq_exit() should be put surrounding the generic IPI handler, in this case, it is generic_smp_call_function_interrupt, if one expects it to run softirqs and etc after the IPI. On x86, it has proper wrapper for the function call IPI, not sure if your platform has it or not? Regards, Rong -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
