* 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-effe
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 wh
> 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
* 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 thi
* 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 expe
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 late
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 h
* 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 theref
> * 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 handl
[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 +++
12 matches
Mail list logo
