From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26188 invoked by alias); 11 May 2007 21:52:59 -0000 Received: (qmail 26181 invoked by uid 22791); 11 May 2007 21:52:58 -0000 X-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_20,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO X-Spam-Check-By: sourceware.org Received: from outpipe-village-512-1.bc.nu (HELO the-village.bc.nu) (81.2.110.250) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 May 2007 21:52:55 +0000 Received: from the-village.bc.nu (localhost.localdomain [127.0.0.1]) by the-village.bc.nu (8.13.8/8.13.8) with ESMTP id l4BLujwc010056; Fri, 11 May 2007 22:56:45 +0100 Date: Fri, 11 May 2007 21:52:00 -0000 From: Alan Cox To: Mathieu Desnoyers Cc: Andi Kleen , systemtap@sources.redhat.com, prasanna@in.ibm.com, ananth@in.ibm.com, anil.s.keshavamurthy@intel.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, hch@infradead.org Subject: Re: [patch 05/10] Linux Kernel Markers - i386 optimized version Message-ID: <20070511225645.1e256ea5@the-village.bc.nu> In-Reply-To: <20070511180207.GA25516@Krystal> References: <20070510015555.973107048@polymtl.ca> <20070510020916.508519573@polymtl.ca> <20070510090656.GA57297@muc.de> <20070510155501.GI22424@Krystal> <20070510172843.7aa72237@the-village.bc.nu> <20070510165918.GK22424@Krystal> <20070511060444.GA35262@muc.de> <20070511180207.GA25516@Krystal> X-Mailer: Claws Mail 2.9.1 (GTK+ 2.10.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00260.txt.bz2 > The IPI might be fast, but I have seen interrupts being disabled for > quite a long time in some kernel code paths. Having interrupts disabled > on _each cpu_ while running an IPI handler waiting to be synchronized > with other CPUs has this side-effect. Therefore, if I understand well, This can already occur worst case when we spin on an IPI (eg a cross CPU TLB shootdown) If the INT3 is acknowledged as safe by intel either as is or by some specific usage like lock mov then great. If not it isn't too bad a problem. And to be real about this - how many benchmarks do you know that care about mega-kernel-debugs per second ?