From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755927Ab0IAPvb (ORCPT ); Wed, 1 Sep 2010 11:51:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62443 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753194Ab0IAPva (ORCPT ); Wed, 1 Sep 2010 11:51:30 -0400 Date: Wed, 01 Sep 2010 11:51:12 -0400 Subject: Re: [PATCH 1/3] [lockup detector] sync touch_*_watchdog back to old semantics Message-ID: From: Don Zickus To: Ingo Molnar , Cyrill Gorcunov Cc: peterz@infradead.org, fweisbec@gmail.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset=utf-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id o81Fpgei008911 Top posting because droid won't let me bottom post This patch was the result of a regression with acpi and preempt. Akpm asked that I not change the semantics of the old touch_nmi_watchdog. So I tried to revert to the old behaviour. Sorry for not properly explaining that. Cheers, Don Ingo Molnar wrote: > >* Cyrill Gorcunov wrote: > >> On 9/1/10, Cyrill Gorcunov wrote: >> > On 9/1/10, Ingo Molnar wrote: >> >> >> >> * Don Zickus wrote: >> >> >> >>> void touch_nmi_watchdog(void) >> >>> { >> >>> - __get_cpu_var(watchdog_nmi_touch) = true; >> >>> + if (watchdog_enabled) { >> >>> + unsigned cpu; >> >>> + >> >>> + for_each_present_cpu(cpu) { >> >>> + if (per_cpu(watchdog_nmi_touch, cpu) != true) >> >>> + per_cpu(watchdog_nmi_touch, cpu) = true; >> >>> + } >> >> >> >> Hm, this is going to be a scalability nightmare with lots of CPUs. Not >> >> only do we have a nr_cpus loop, but we touch per-cpu areas of _other_ >> >> CPUs - a big scalability nono. >> >> >> >> Why do we need to do this? We never needed to touch other CPU's NMI >> >> lockup accounting data areas - why has this changed? The changelog does >> >> not explain this. >> >> >> >> Thanks, >> >> >> >> Ingo >> >> >> > I believe this came from old nmi watchdog code where it might be >> > useful when nmi watchdog activated via io-apic. I'm trying to figure >> > out if we really need it still. >> >> Well, we can't drop it or make per-cpu specific, for example we need >> it in case of panic with watchdog enabled and panic timeout set, or >> boot delay set and etc. Seems same applies to printk_delay. Hmm... > >Ok - can you cite the old watchdog code, did it really do a nr_cpus >loop? > >Thanks, > > Ingo {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I