Jeremy Fitzhardinge wrote: > 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 > You don't have to do them all -- you could do one with (as in my previous patch -- which I'm not married to BTW ;) ) touch_cpu_softlockup_watchdog() and all with touch_softlockup_watchdog() > 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. > > But wouldn't a call to touch_[cpu_]softlockup_watchdog at the end of the flash update fix the problem? And ditto for all other areas of the kernel where we know we're holding off scheduling? P. > J > _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
