Prarit Bhargava wrote: > I don't like the idea of having touch_softlockup_watchdog exported > with your new code -- we still have two methods of effecting the > softlockup watchdog and that's confusing and its going to cause > serious problems down the road. It's legacy. There are a few places where it wasn't obvious to me how to replace the touch_softlockup_watchdog, so I left them for now. But ideally I think they should all go away. > Is there a reason that you're pushing the enable/disable? All the > cases called out seem to be just fine with calls to either effect that > CPU's softlockup watchdog or doing all CPU's softlockup watchdogs. Doing all CPUs is meaningless to me. How does that make sense? It might work in the sense that messages go away, but doesn't it just hide the fact that one CPU has gone into a spin? > I agree with the first patch of this set -- it makes sense. But > beyond that I'm not convinced the rest of the code is needed ... IMO. Zach has reported seeing spurious softlockup messages on idle machines running under a hypervisor. And there was also the discussion about how to deal with a flash update system in which all CPUs are taken over by the bios for a long period of time, which was causing softlockup to trigger. It seemed to me that these could all be dealt with in much the same way, and that disable/enable semantics for dealing with long-running timer holdoffs is more natural than trying to work out how to periodically touch the watchdog timer. J _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization