From: Mikael P. <mi...@it...> - 2007-06-26 08:19:32
|
On Mon, 25 Jun 2007 23:04:25 +0200, B.S...@gm... wrote: > > I think the tricky part is that we do want to reserve perfctr1 even > > though the NMI watchdog is not active. This comes from the fact that > > the NMI watchdog knows about only one counter and if it can't get that > > one, it probably fails. By reserving it from the start, we ensure NMI > > watchdog will work when eventually activated. > > Can you enable it later on at all? It failed for me when I tried, > because it didn't know which hardware to use. Had to pass the kernel > parameter to make the proc files do anything. Seems like it has to be > enable at boot to work at all. > > And AFAICT we never unconditionally reserved a perfctr for the watchdog. Yes you can dynamically enable/disable the NMI watchdog, at least if you booted with it enabled. > In 2.6.21 the nmi watchdog, if enabled, just reserved its perfctrs and > everything else had to deal with it. Since the cleanup, the watchdog > will release its perfctr when disabled, so another subsystem can grab > it. But that also means that that other subsystem must release it again > before you can reenable the watchdog. Which is the obvious and correct way to handle a shared resource. Keeping parts of the PMU HW permanently reserved whether or not the watchdog is enabled would be a BUG. /Mikael |
From: Mikael P. <mi...@it...> - 2007-06-26 10:50:40
|
On Tue, 26 Jun 2007 02:57:55 -0700, Mikael Pettersson wrote: > > Keeping parts of the PMU HW permanently reserved whether or not > > the watchdog is enabled would be a BUG. > > > True. But the upside is that you guarantee the activation of the NMI > watchdog will always succeed which may be a valuable property given the > goal of the NMI watchdog. Otherwise, if Oprofile or perfmon are active, > the NMI will fail to grab a single counter. That relates more to policy than mechanism. I for one don't consider the watchdog "sacred". I think it's entirely reasonable that if the watchdog is disabled (echo 0 > /proc/sys/kernel/nmi_watchdog) in order to give the _full_ PMU HW to something else, then that something else needs to be disabled (or otherwise instructed to give up the HW) before the watchdog can be reenabled. If you don't want to risk not being able to restart the watchdog, don't disable it. |
From: Stephane E. <er...@hp...> - 2007-06-26 09:58:15
|
Mikael, On Tue, Jun 26, 2007 at 10:04:15AM +0200, Mikael Pettersson wrote: > On Mon, 25 Jun 2007 23:04:25 +0200, B.S...@gm... wrote: > > > I think the tricky part is that we do want to reserve perfctr1 even > > > though the NMI watchdog is not active. This comes from the fact that > > > the NMI watchdog knows about only one counter and if it can't get that > > > one, it probably fails. By reserving it from the start, we ensure NMI > > > watchdog will work when eventually activated. > > > > Can you enable it later on at all? It failed for me when I tried, > > because it didn't know which hardware to use. Had to pass the kernel > > parameter to make the proc files do anything. Seems like it has to be > > enable at boot to work at all. > > > > And AFAICT we never unconditionally reserved a perfctr for the watchdog. > > Yes you can dynamically enable/disable the NMI watchdog, > at least if you booted with it enabled. > > > In 2.6.21 the nmi watchdog, if enabled, just reserved its perfctrs and > > everything else had to deal with it. Since the cleanup, the watchdog > > will release its perfctr when disabled, so another subsystem can grab > > it. But that also means that that other subsystem must release it again > > before you can reenable the watchdog. > > Which is the obvious and correct way to handle a shared resource. > Agreed. > Keeping parts of the PMU HW permanently reserved whether or not > the watchdog is enabled would be a BUG. > True. But the upside is that you guarantee the activation of the NMI watchdog will always succeed which may be a valuable property given the goal of the NMI watchdog. Otherwise, if Oprofile or perfmon are active, the NMI will fail to grab a single counter. -- -Stephane |