On Sun, Jan 27, 2019 at 01:15:31AM +0000, Paul Walmsley wrote: > On Sat, 26 Jan 2019, Russell King - ARM Linux admin wrote: > > > On Sat, Jan 26, 2019 at 09:00:03PM +0000, Paul Walmsley wrote: > > > On Fri, 25 Jan 2019, Tony Lindgren wrote: > > > > > > > * Russell King <rmk+kernel@xxxxxxxxxxxxxxx> [190125 21:04]: > > > > > Executing loops such as: > > > > > > > > > > while (1) > > > > > cpu_relax(); > > > > > > > > > > with interrupts disabled results in a livelock of the entire system, > > > > > as other CPUs are prevented making progress. This is most noticable > > > > > as a failure of crashdump kexec, which stops just after issuing: > > > > > > > > > > Loading crashdump kernel... > > > > > > > > > > to the system console. A workaround for this is to use 10 nops in > > > > > cpu_relax(). > > > > > > > > > > We also use wfe() in while (1) loops to avoid burning cycles in a > > > > > tight loop, giving the CPU a hint that we're not doing anything > > > > > useful. > > > > > > > > > > Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxx> > > > > > --- > > > > > It's been a while since this was posted, Will's suggestion was to use > > > > > 10 nops in cpu_relax() last time around. I still prefer wfe() in > > > > > these infinite-not-doing-anything-ever loops. > > > > > > > > Works for me: > > > > > > > > Tested-by: Tony Lindgren <tony@xxxxxxxxxxx> > > > > > > There was some concern in the past that WFE, like WFI, might cause the > > > core to assert an external signal that might cause the SoC integration to > > > place the core into a low-power mode from which it might not be able to > > > wake up. This could happen on OMAP, for example, with WFI. > > > > > > I don't recall the outcome of those discussions. Was a conclusion ever > > > reached? > > > > First, we use WFE in spinlocks. If WFE were to place the CPU in a > > low power state that it may not be able to wake up from, all our > > spinlocks would be unsafe. > > Good point. WFE must not assert the external signal that indicates > that the core is inactive. > > > Next, in all of the situations in this patch, we're executing an > > infinite loop. If it were to cause the core to go into a low power > > mode, surely that's a good thing, rather than the core endlessly > > executing NOPs? The only way out of that is for the core to receive > > a reset _anyway_. > > Makes sense. > > Do you recall what Will's reasoning was for preferring 10 NOPs to a WFE? I think there may be an erratum for this which specifies 10 NOPs as its workaround, but I don't have its number. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
