On 04/02/12 04:55, rong wrote:
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
Thanks Rong, that was a good suggestion.
do_IPI() in arch/arm/kernel/smp.c did not call irq_enter and irq_exit.
Other interrupts call it, but for some reason this did not. (Although,
ipi_timer does).
Adding these calls allows the callback to processed during irq_exit, and
my 5 minute stall no longer occurs.
Thanks.
Bob.
--
unsubscribe: [email protected]
website: http://groups.google.com/group/android-kernel
