* 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
* 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.
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
> 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
* 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
* 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
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
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
* 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
* 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
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
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.
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
* 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
> * 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
* 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?
>
>
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
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
* 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
* 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
* 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
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
[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
[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
24 matches
Mail list logo