Re: [patch 05/10] Linux Kernel Markers - i386 optimized version

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> * 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