RCU lockup issues when CONFIG_SOFTLOCKUP_DETECTOR=n - any one else seeing this?
Jonathan.Cameron at huawei.com
Thu Jul 27 17:41:56 AEST 2017
On Wed, 26 Jul 2017 18:13:12 +0100
Jonathan Cameron <Jonathan.Cameron at huawei.com> wrote:
> On Wed, 26 Jul 2017 09:54:32 -0700
> David Miller <davem at davemloft.net> wrote:
> > From: "Paul E. McKenney" <paulmck at linux.vnet.ibm.com>
> > 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).
> > 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 at huawei.com
More information about the Linuxppc-dev