Re: [nohz] 2a16fc93d2c: kernel lockup on idle injection
From: Thomas Gleixner
Date: Tue Dec 16 2014 - 11:55:22 EST
On Tue, 16 Dec 2014, Peter Zijlstra wrote:
> On Tue, Dec 16, 2014 at 03:32:28PM +0100, Thomas Gleixner wrote:
> So let me try and understand the problem with the emulated idle thing
> better (running idle from FIFO threads).
>
> I suppose the tricky bit is what happens when the cpu was idle; in that
> case we'll end up with 1 running thread in state:
>
> 1 0 1 valid
>
> But need to avoid ending up in:
>
> 1 1 1 BUG
>
> Which should be relatively simple by never entering nohzfull when 'idle'.
Well, yes.
> However with your proposed thingy, I think we'll end up in:
>
> 1 1 1 BUG
>
> Because we don't start another thread, so infullnohz will stay valid,
> however we'll also be 'forced' into idle (with nr_running > 0) and stop
> the tick.
Indeed.
> A remote wakeup might result in nr_running going from 1->2 and seeing
> infullnohz == 1, try and restart the tick, while we're idle!
>
> Of course, we can fix that too, by clearing nohzfull when going 'idle',
> after all, nohzfull will re-establish itself automagically when the tick
> detects but the one task afterwards.
>
> So both cases need work, neither works out of the box afaict. But I
Agreed.
> can't see one really being better than the other either -- am I missing
> obvious things again?
No, it's both butt ugly, though what really bothers me is that we
pretend to be idle without being in the idle thread. That makes a lot
of stuff really weird.
Anything which relies on is_idle_task(current), idle_cpu() and a bunch
of other things just fail to work while we pretend being "the idle"
task.
That's just wrong. That powerclamp stuff needs to put the cpu
(including the scheduler, etc.) into a well defined state.
The fake idle task is everything else than well defined state, really.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/