Re: [patch 3/4] Locally disable the softlockup watchdog rather thantouching it

From: Prarit Bhargava
Date: Wed Mar 28 2007 - 10:52:29 EST




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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/