Re: [git pull] scheduler/misc fixes

[Ingo Molnar <mingo@elte.hu>]

* Peter Zijlstra <peterz@infradead.org> wrote:

> OK, so David came up with the idea that it might be the reschedule IPI 
> (smp_receive_signal_client) that did the wakeup resulting in the 
> following scenario:
> 
>  <idle > 60s >
>  <resched-IPI> -> nohz_restart() -> restart timer
>                                  -> schedule()
> 
>  <run stuff>
>  <timer> -> softlockup_tick() -> BUG!
>  
> doing irq_enter/exit() for smp_receive_signal_client() did indeed fix
> the whole issue. (x86 also has this bug - its just darn hard to generate
> 60s+ nohz periods due to the shitty clocks/timers)
> 
> So per b) any nohz wake needs to be done with an interrupt _and_ all
> such interrupts must pass through irq_enter().
> 
> As far as I can tell this is not nessecarily true (or desired from a 
> performance POV) for all platforms, imagine the core2 monitor/mwait 
> idle that wakes up because of a memory write. This doesn't require an 
> interrupt at all to wake up.
> 
> So, are we going to require all waking interrupts (IPIs and regular) 
> to do the irq_enter/exit() dance and add the perhaps unneeded overhead 
> to these paths and require the non-interrupt driven wake-ups like 
> monitor/mwait to do the touch_softlockup_watchdog() themselves?
> 
> Or,
> 
> Is Ingo's initial patch to make nohz_restart() also touch the 
> softlockup watchdog the best fix (now that we understand what 
> happens)?

thanks Peter for the detailed analysis.

I think we should not require all IRQ contexts to do irq_enter/exit - 
not because of the overhead (these are mainly really small costs), but 
mostly because as this example has shown, nothing besides this rather 
elusive softlockup false-positive enforces their correctness. So we'll 
always lag behind significantly and wont ever achieve a truly correct 
solution.

a much stronger approach would be to: require all exit-idle paths to 
touch the softlockup watchdog (we are evidently not locked up there), 
and require the timer IRQ to touch it as well if it hits an idle 
context. We restart the scheduler tick in the exit-idle path anyway, 
otherwise the scheduler breaks visibly - so that's the right place to 
put the touch_softlockup_watchdog() call.

I.e. i'd pretty much concur with you that the best solution is the very 
first patch - which is also in the pull to Linus - we just now 
understand exactly why ;-) David, do you agree?

	Ingo