Re: [tip:timers/urgent] tick: Cleanup NOHZ per cpu data on cpudown

[Thomas Gleixner]

On Mon, 13 May 2013, Prarit Bhargava wrote:
> Thomas, while this does fix up the NULL pointer issue, I think you've introduced
> a new bug in the schedule timer code.

I don't think that I introduced a new bug. I'm quite sure that change
unearthed another issue which was papered over by the stale data.

That memset is putting the data structure into the same state as we
have on boot. From tick-sched perspective cpu onlining is not
different between boot and an offline/online cycle

> While doing up and downs on the same CPU, I now occasionally see long delays in
> the up and down...

> [   81.744565] smpboot: Booting Node 1 Processor 19 APIC 0x28
> [   82.848591] smpboot: CPU 19 is now offline
> 
> Long delay in bringing CPU "up"
> 
> [   89.826533] smpboot: Booting Node 1 Processor 19 APIC 0x28
> [   84.905358] smpboot: CPU 19 is now offline
> [   87.565274] smpboot: Booting Node 1 Processor 19 APIC 0x28

Errm, the timestamps are random. -ENOTUSEFUL
 
> Also, if the system is in this state I cannot reboot -- the system appears to
> hang while bringing down CPUs...
> 
> Oddly, if I do
> 
> +       memset(ts, 0, sizeof(*ts));
> +       ts->tick_stopped = 1;
> 
> instead of your memset, everything works.  I'm looking at the tick-sched.c code
> to see why setting tick_stopped = 1 seems to fix the problem.

That doesn't make any sense. So instead of changing random values in
ts, could you please fire up the tracer and gather evidence, so we can
see what the system does when these long delays happen. You can start
and stop the tracer from your script and terminate if one of the
operations takes too long.

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/