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
