On Wed, 15 May 2013, Frederic Weisbecker wrote:
> On Tue, May 14, 2013 at 08:46:59AM -0700, tip-bot for Thomas Gleixner wrote:
> > Commit-ID: f7ea0fd639c2c48d3c61b6eec75362be290c6874
> > Gitweb:
> > http://git.kernel.org/tip/f7ea0fd639c2c48d3c61b6eec75362be290c6874
> > Author: Thomas Gleixner <t...@linutronix.de>
> > AuthorDate: Mon, 13 May 2013 21:40:27 +0200
> > Committer: Thomas Gleixner <t...@linutronix.de>
> > CommitDate: Tue, 14 May 2013 17:40:31 +0200
> >
> > tick: Don't invoke tick_nohz_stop_sched_tick() if the cpu is offline
> >
> > commit 5b39939a4 (nohz: Move ts->idle_calls incrementation into strict
> > idle logic) moved code out of tick_nohz_stop_sched_tick() and missed
> > to bail out when the cpu is offline. That's causing subsequent
> > failures as an offline CPU is supposed to die and not to fiddle with
> > nohz magic.
>
> I don't see the logic has changed after this commit. The old nohz
> code was already shutting down the tick on offline CPUs.
Hmm, you're right. Soemthing tricked me.
> Am I missing something?
> I'm not sure which behaviour we want though, nor what the side
> effect could be whether we keep or shutdown the tick.
>
> There is also the problem of full dynticks CPUs that have their
> tick stopped and then get later offlined. They may end up in the idle loop
> with the tick already stopped and it's not going to be restarted. I believe
> that can trigger the same issue.
>
> I'm just not sure what I should do: restart the tick when the CPU
> is offlining? What could be the side effect of that?
No, it's not about restarting the tick. It's about not falling into
the nohz functions when the cpu is about to die. Just leave it alone,
that's what the patch does.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
