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

2007-05-13 Thread Mathieu Desnoyers
* Alan Cox ([EMAIL PROTECTED]) wrote: > > 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

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

2007-05-13 Thread Mathieu Desnoyers
* Alan Cox ([EMAIL PROTECTED]) wrote: 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.

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

2007-05-11 Thread Suparna Bhattacharya
On Fri, May 11, 2007 at 10:27:29AM +0530, Ananth N Mavinakayanahalli wrote: > On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: > > * Alan Cox ([EMAIL PROTECTED]) wrote: > > ... > > > > * Third issue : Scalability. Changing code will stop every CPU on the > > > > system for a

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

2007-05-11 Thread Alan Cox
> 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

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

2007-05-11 Thread Mathieu Desnoyers
* Ananth N Mavinakayanahalli ([EMAIL PROTECTED]) wrote: > On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: > > * Alan Cox ([EMAIL PROTECTED]) wrote: > > ... > > > > * Third issue : Scalability. Changing code will stop every CPU on the > > > > system for a while. Compared to

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

2007-05-11 Thread Mathieu Desnoyers
* Andi Kleen ([EMAIL PROTECTED]) wrote: > On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: > > * Alan Cox ([EMAIL PROTECTED]) wrote: > > > > * First issue : Impact on the system. If we try to make this system > > > > scale, we will create very long irq disable sections. The

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

2007-05-11 Thread Andi Kleen
On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: > * Alan Cox ([EMAIL PROTECTED]) wrote: > > > * 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

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

2007-05-11 Thread Andi Kleen
On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: * Alan Cox ([EMAIL PROTECTED]) wrote: * 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

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

2007-05-11 Thread Mathieu Desnoyers
* Andi Kleen ([EMAIL PROTECTED]) wrote: On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: * Alan Cox ([EMAIL PROTECTED]) wrote: * First issue : Impact on the system. If we try to make this system scale, we will create very long irq disable sections. The expected

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

2007-05-11 Thread Mathieu Desnoyers
* Ananth N Mavinakayanahalli ([EMAIL PROTECTED]) wrote: On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: * Alan Cox ([EMAIL PROTECTED]) wrote: ... * Third issue : Scalability. Changing code will stop every CPU on the system for a while. Compared to this, the

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

2007-05-11 Thread Alan Cox
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

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

2007-05-11 Thread Suparna Bhattacharya
On Fri, May 11, 2007 at 10:27:29AM +0530, Ananth N Mavinakayanahalli wrote: On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: * Alan Cox ([EMAIL PROTECTED]) wrote: ... * Third issue : Scalability. Changing code will stop every CPU on the system for a while.

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

2007-05-10 Thread Ananth N Mavinakayanahalli
On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: > * Alan Cox ([EMAIL PROTECTED]) wrote: ... > > > * 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

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

2007-05-10 Thread Mathieu Desnoyers
* Alan Cox ([EMAIL PROTECTED]) wrote: > > * 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

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

2007-05-10 Thread Alan Cox
> * 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

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

2007-05-10 Thread Mathieu Desnoyers
* Andi Kleen ([EMAIL PROTECTED]) wrote: > On Wed, May 09, 2007 at 09:56:00PM -0400, Mathieu Desnoyers wrote: > > @@ -0,0 +1,99 @@ > > +/* marker.c > > + * > > + * Erratum 49 fix for Intel PIII and higher. > > Errata are CPU specific so they can't be higher. You mean it's a P3 > erratum only? > >

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

2007-05-10 Thread Andi Kleen
On Wed, May 09, 2007 at 09:56:00PM -0400, Mathieu Desnoyers wrote: > @@ -0,0 +1,99 @@ > +/* marker.c > + * > + * Erratum 49 fix for Intel PIII and higher. Errata are CPU specific so they can't be higher. You mean it's a P3 erratum only? In general you need some more description why the int3

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

2007-05-10 Thread Andi Kleen
On Wed, May 09, 2007 at 09:56:00PM -0400, Mathieu Desnoyers wrote: @@ -0,0 +1,99 @@ +/* marker.c + * + * Erratum 49 fix for Intel PIII and higher. Errata are CPU specific so they can't be higher. You mean it's a P3 erratum only? In general you need some more description why the int3 handler

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

2007-05-10 Thread Mathieu Desnoyers
* Andi Kleen ([EMAIL PROTECTED]) wrote: On Wed, May 09, 2007 at 09:56:00PM -0400, Mathieu Desnoyers wrote: @@ -0,0 +1,99 @@ +/* marker.c + * + * Erratum 49 fix for Intel PIII and higher. Errata are CPU specific so they can't be higher. You mean it's a P3 erratum only? In general

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

2007-05-10 Thread Alan Cox
* 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

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

2007-05-10 Thread Mathieu Desnoyers
* Alan Cox ([EMAIL PROTECTED]) wrote: * 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

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

2007-05-10 Thread Ananth N Mavinakayanahalli
On Thu, May 10, 2007 at 12:59:18PM -0400, Mathieu Desnoyers wrote: * Alan Cox ([EMAIL PROTECTED]) wrote: ... * 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

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

2007-05-09 Thread Mathieu Desnoyers
[EMAIL PROTECTED]: marker exports must be EXPORT_SYMBOL_GPL] Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- arch/i386/kernel/Makefile |1 arch/i386/kernel/marker.c | 99

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

2007-05-09 Thread Mathieu Desnoyers
[EMAIL PROTECTED]: marker exports must be EXPORT_SYMBOL_GPL] Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] Cc: Andi Kleen [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- arch/i386/kernel/Makefile |1 arch/i386/kernel/marker.c | 99