This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [patch 05/10] Linux Kernel Markers - i386 optimized version
- From: Alan Cox <alan at lxorguk dot ukuu dot org dot uk>
- To: Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Cc: Andi Kleen <ak at muc dot de>, systemtap at sources dot redhat dot com, prasanna at in dot ibm dot com, ananth at in dot ibm dot com, anil dot s dot keshavamurthy at intel dot com, akpm at linux-foundation dot org, linux-kernel at vger dot kernel dot org, hch at infradead dot org
- Date: Fri, 11 May 2007 22:56:45 +0100
- Subject: Re: [patch 05/10] Linux Kernel Markers - i386 optimized version
- 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>
> 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 ?