Re: [PATCH] nmi_watchdog=2 and P4-HT

[Philippe Elie]

On Wed, 03 Mar 2004 at 22:32 +0000, Andrew Morton wrote:

> Philippe Elie <phil.el@xxxxxxxxxx> wrote:
> >
> > 
> >  What do you think about the feature "the performance doesn't increment
> >  counter in hlt mode".
> 
> That sounds OK.  If the CPU halts with local interrupts disabled (is this
> possible?) then I assume it'll never come back.  But this possibility isn't
> worth worrying about, surely.
> 
> Can we scale the performance counter multiplier down a bit?  1000 NMIs per
> second sounds excessive.

yups and on HT it's 2000 NMI on one physical processor

I think to something like this, it's just a quick draw so you get the
idea. it's the less bad patch I can provide, get a look at the apic.c
chunk, I needed to remove the check_nmi_watchdog(); test for UP else
this test will complete in 10 seconds. Look like ugly but anyway on
SMP and with nmi_watchdog=2 we never call check_nmi_watchdog() and
I think the purpose of check_nmi_watchdog() is to test IO apic not
local apic after all if a local apic is up it must be sane ?

Phil sleeping

--- linux-2.6/arch/i386/kernel/nmi.c~	2004-03-04 08:05:48.000000000 +0000
+++ linux-2.6/arch/i386/kernel/nmi.c	2004-03-04 08:05:55.000000000 +0000
@@ -347,6 +347,8 @@ static int setup_p4_watchdog(void)
 
 void setup_apic_nmi_watchdog (void)
 {
+	nmi_hz = 1;
+
 	switch (boot_cpu_data.x86_vendor) {
 	case X86_VENDOR_AMD:
 		if (boot_cpu_data.x86 != 6 && boot_cpu_data.x86 != 15)
--- linux-2.6.orig/arch/i386/kernel/apic.c	2004-03-04 05:05:19.000000000 +0000
+++ linux-2.6/arch/i386/kernel/apic.c	2004-03-04 07:44:50.000000000 +0000
@@ -1182,9 +1182,6 @@ int __init APIC_init_uniprocessor (void)
 	phys_cpu_present_map = physid_mask_of_physid(boot_cpu_physical_apicid);
 
 	setup_local_APIC();
-
-	if (nmi_watchdog == NMI_LOCAL_APIC)
-		check_nmi_watchdog();
 #ifdef CONFIG_X86_IO_APIC
 	if (smp_found_config)
 		if (!skip_ioapic_setup && nr_ioapics)
-
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/