On 07/01/13 14:24, Thomas Gleixner wrote: > On Mon, 1 Jul 2013, Stephen Boyd wrote: >> On 07/01/13 13:14, Thomas Gleixner wrote: >>> The issue is very subtle. What happens is: >>> >>> CPU0 CPU1 >>> >>> Switch to oneshot mode >>> >>> Copy the bits from tick_broadcast_mask to >>> tick_broadcast_oneshot_mask. We need to do >>> that so the other cpus reach the timer irq >>> and the softirq which switches them to >>> oneshot. >>> >>> Kick the broadcast device into oneshot. >>> >>> Timer interrupt fires >>> >>> irq_enter sees the cpu in >>> tick_broadcast_oneshot_mask and >>> sets the device to oneshot mode >>> >>> handle_periodic: >>> Sees oneshot mode and adds >>> period to >>> dev->next_event(KTIME_MAX) >>> >> Yep. It is also racing with the timer interrupt so having more than two >> CPUs must help widen the window (which is why we see it on the higher >> numbered CPUs). > The race above is about the timer interrupt. You mean the broadcast > one which is still enabled due to the dummy -> functional transition > issue, right? That helps a lot to make this more visible, because we > double the number of events. I was thinking that tick_check_oneshot_broadcast() is racing with tick_switch_to_oneshot() and because we have more CPUs we're more likely to have a CPU fix up the handler in tick_switch_to_oneshot() after tick_check_oneshot_broadcast() forces that CPU to oneshot mode and the periodic handler runs. I wonder if I can reproduce it locally by making tick_switch_to_oneshot() spin for a jiffy or two on CPU1. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
