On 06/19/2018 05:15 PM, Ricardo Neri wrote: > On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote: >> On Fri, 15 Jun 2018, Ricardo Neri wrote: >>> On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote: >>>> On Thu, 14 Jun 2018, Ricardo Neri wrote: >>>>> Alternatively, there could be a counter that skips reading the HPET status >>>>> register (and the detection of hardlockups) for every X NMIs. This would >>>>> reduce the overall frequency of HPET register reads. >>>> >>>> Great plan. So if the watchdog is the only NMI (because perf is off) then >>>> you delay the watchdog detection by that count. >>> >>> OK. This was a bad idea. Then, is it acceptable to have an read to an HPET >>> register per NMI just to check in the status register if the HPET timer >>> caused the NMI? >> >> The status register is useless in case of MSI. MSI is edge triggered .... >> >> The only register which gives you proper information is the counter >> register itself. That adds an massive overhead to each NMI, because the >> counter register access is synchronized to the HPET clock with hardware >> magic. Plus on larger systems, the HPET access is cross node and even >> slower. > > It starts to sound that the HPET is too slow to drive the hardlockup detector. > > Would it be possible to envision a variant of this implementation? In this > variant, the HPET only targets a single CPU. The actual hardlockup detector > is implemented by this single CPU sending interprocessor interrupts to the > rest of the CPUs. > > In this manner only one CPU has to deal with the slowness of the HPET; the > rest of the CPUs don't have to read or write any HPET registers. A sysfs > entry could be added to configure which CPU will have to deal with the HPET > timer. However, profiling could not be done accurately on such CPU.
Please forgive my simple question: What happens when this one CPU is the one that locks up? thnx, -- ~Randy _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
