Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 16 Nov 2002 21:21:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 16 Nov 2002 21:21:31 -0500 Received: from modemcable017.51-203-24.mtl.mc.videotron.ca ([24.203.51.17]:34354 "EHLO montezuma.mastecende.com") by vger.kernel.org with ESMTP id ; Sat, 16 Nov 2002 21:21:31 -0500 Date: Sat, 16 Nov 2002 21:31:55 -0500 (EST) From: Zwane Mwaikambo X-X-Sender: zwane@montezuma.mastecende.com To: John Levon cc: Corey Minyard , Linus Torvalds , Subject: Re: NMI handling rework for x86 In-Reply-To: <20021117020017.GA96715@compsoc.man.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1055 Lines: 25 On Sun, 17 Nov 2002, John Levon wrote: > One thing: since we have the unnatural relationship between the watchdog > and oprofile, I would much prefer that be obvious in the priority. e.g > MAX_NMI_PRIORITY, which oprofile uses, then watchdog is MAX_NMI_PRIORITY > -1. Currently the gap between the two values you use indicates it's OK > to have another handler inbetween, which it definitely isn't. Hmm how about when the machine really is in trouble, we really wouldn't want some things to be running when we want the watchdog to trigger. How do you propose we handle this? nmi_watchdog_tick is pretty light so it has a lesser chance of blowing up in various code when the machine is on the brink of death. 150,000? Nice Corey, again i stand corrected on that front. Zwane -- function.linuxpower.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/