On Wed, 26 Jul 2017 18:13:12 +0100 Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > On Wed, 26 Jul 2017 09:54:32 -0700 > David Miller <davem@xxxxxxxxxxxxx> wrote: > > > From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx> > > Date: Wed, 26 Jul 2017 08:49:00 -0700 > > > > > On Wed, Jul 26, 2017 at 04:33:40PM +0100, Jonathan Cameron wrote: > > >> Didn't leave it long enough. Still bad on 4.10-rc7 just took over > > >> an hour to occur. > > > > > > And it is quite possible that SOFTLOCKUP_DETECTOR=y and HZ_PERIODIC=y > > > are just greatly reducing the probability of the problem rather than > > > completely preventing it. > > > > > > Still, hopefully useful information, thank you for the testing! > > Not sure it actually gives us much information, but no issues yet > with a simple program running every cpu that wakes up every 3 seconds. > > Will leave it running overnight and report back in the morning. Perhaps unsurprisingly the above test didn't show any splats. So it appears a userspace wakeup is enough to stop the issue happening (or at least make it a lot less likely). Jonathan > > > > > I guess that invalidates my idea to test reverting recent changes to > > the tick-sched.c code... :-/ > > > > In NO_HZ_IDLE mode, what is really supposed to happen on a completely > > idle system? > > > > All the cpus enter the idle loop, have no timers programmed, and they > > all just go to sleep until an external event happens. > > > > What ensures that grace periods get processed in this regime? > _______________________________________________ > linuxarm mailing list > linuxarm@xxxxxxxxxx > http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
