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: Thu, 10 May 2007 17:28:43 +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>
> * First issue : Impact on the system. If we try to make this system
> scale, we will create very long irq disable sections. The expected
> duration is the worse case IPI latency plus the time it takes to CPU A
> to change the variable. We therefore directly grow the worse case
> system's interrupt latency.
Not a huge problem. It doesn't scale in really horrible ways and the IPI
latency on a PIV or later is actually very good. Also the impact is less
than you might think as on huge huge boxes you want multiple copies of
the kernel text pages to reduce NUMA traffic, so you only have to sync
the group of processors involved
> * Second issue : irq disabling does not protect us from NMI and traps.
> We cannot use this algorithm to mark these code segments.
If you synchronize all the other processors and disable local interrupts
then the only traps you have to worry about are those you cause, and the
only person taking the trap will be you so you're ok.
NMI is hard but NMI is a special case not worth solving IMHO.
> * Third issue : Scalability. Changing code will stop every CPU on the
> system for a while. Compared to this, the int3-based approach will run
> through the breakpoint handler "if" one of the CPU happens to execute
> this code at the wrong time. The standard case is just an IPI (to
If I read the errata right then patching in an int3 will itself trigger
the errata so anything could happen.
I believe there are other safe sequences for doing code patching - perhaps
one of the Intel folk can advise ?
Alan