On Thu, May 31, 2007 at 07:29:43AM -0600, Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> writes:
>
> > On Thursday 31 May 2007 13:34:21 Eric W. Biederman wrote:
> >>
> >> On x86_64 kernel, level triggered irq migration gets initiated in the
> >> context
> >> of that interrupt(after ex
On Thu, May 31, 2007 at 07:50:58AM -0600, Eric W. Biederman wrote:
>
> On x86_64 kernel, level triggered irq migration gets initiated in the context
> of that interrupt(after executing the irq handler) and following steps are
> followed to do the irq migration.
>
> 1. mask IOAPIC RTE entry; /
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Initial analysis and patch from Nanhai.
>
> Clean up patch from Suresh.
>
> Rewritten to be less intrusive, and to contain a big fat comment by
> Eric.
thanks Erik!
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux
On x86_64 kernel, level triggered irq migration gets initiated in the context
of that interrupt(after executing the irq handler) and following steps are
followed to do the irq migration.
1. mask IOAPIC RTE entry; // write to IOAPIC RTE
2. EOI; // processor EOI write
3. r
looks good to me:
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
with a few minor style nits:
> +static int io_apic_level_ack_pending(unsigned int irq)
> +{
> + struct irq_pin_list *entry;
> + unsigned long flags;
> + int pending = 0;
> + spin_lock_irqsave(&ioapic_lock, flags);
ne
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Thursday 31 May 2007 13:34:21 Eric W. Biederman wrote:
>>
>> On x86_64 kernel, level triggered irq migration gets initiated in the context
>> of that interrupt(after executing the irq handler) and following steps are
>> followed to do the irq migration.
On Thursday 31 May 2007 13:34:21 Eric W. Biederman wrote:
>
> On x86_64 kernel, level triggered irq migration gets initiated in the context
> of that interrupt(after executing the irq handler) and following steps are
> followed to do the irq migration.
What's the confidence level in the patch? Is
On x86_64 kernel, level triggered irq migration gets initiated in the context
of that interrupt(after executing the irq handler) and following steps are
followed to do the irq migration.
1. mask IOAPIC RTE entry; // write to IOAPIC RTE
2. EOI; // processor EOI write
3. r
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:
> Eric,
>
> On Fri, May 18, 2007 at 07:40:53AM -0700, Eric W. Biederman wrote:
>> Still in any of those I don't see a problem with switching to edge
>> triggered mode and then back again. Either Remote IRR will keep
>> it's current state or it will b
On Fri, May 18, 2007 at 12:02:16PM -0700, Eric W. Biederman wrote:
> I will look closer but I do believe that from the ioapic to the cpu the 2.6.21
> code should be fairly robust with respect to inflight messages from the ioapic
> to the local apics and the cpus. What I failed to consider were inf
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:
> On Fri, May 18, 2007 at 11:28:25AM -0700, Yinghai Lu wrote:
>> On 5/18/07, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
>> >
>> > If the vector number stays same during irq migration and if we reset remote
>> > IRR bit using the above method(edge and
On Fri, May 18, 2007 at 11:28:25AM -0700, Yinghai Lu wrote:
> On 5/18/07, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> >
> > If the vector number stays same during irq migration and if we reset remote
> > IRR bit using the above method(edge and then back to level) during
> > irq migration, then we
On 5/18/07, Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
If the vector number stays same during irq migration and if we reset remote
IRR bit using the above method(edge and then back to level) during
irq migration, then we have a problem. A new interrupt arriving on a new
cpu will set the remote
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> On 5/18/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> We can solve the problem without doing that, and keeping the same
>> vector number during migration keeps x86 from scaling.
>
> I mean ioapic level irq couls be limited. new device could use MSI
Eric,
On Fri, May 18, 2007 at 07:40:53AM -0700, Eric W. Biederman wrote:
> Still in any of those I don't see a problem with switching to edge
> triggered mode and then back again. Either Remote IRR will keep
> it's current state or it will be cleared. Remote IRR should not
> get set (when it wa
On 5/18/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
We can solve the problem without doing that, and keeping the same
vector number during migration keeps x86 from scaling.
I mean ioapic level irq couls be limited. new device could use MSI or
HT irq directly and less irq routing problem.
"Yinghai Lu" <[EMAIL PROTECTED]> writes:
> Eric,
>
> ioapic_level irq is limited, So if we keep vector number not changed
> when imgration to other cpus. It that could help.
We can solve the problem without doing that, and keeping the same
vector number during migration keeps x86 from scaling.
Eric,
ioapic_level irq is limited, So if we keep vector number not changed
when imgration to other cpus. It that could help.
it will need modify a little with assign_irq_vector and
irq_complete_move/smp_irq_move_cleanup_interrupt. because it assume
vector must be changed.
YH
-
To unsubscribe f
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:
> On Thu, May 17, 2007 at 05:30:13PM -0700, Eric W. Biederman wrote:
>> So why does any of this matter?
>>
>> My memory says that the ioapic state for sending irqs gets reset when we
>> unmask the irq.
>
> No. Atleast not on the platform we have teste
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Friday 18 May 2007 01:03, Siddha, Suresh B wrote:
>
>> Normally, the EOI generated by local APIC for level trigger interrupt
>> contains vector number. The IOAPIC will take this vector number and
>> search the IOAPIC RTE entries for an entry with matchin
On Friday 18 May 2007 01:03, Siddha, Suresh B wrote:
> Normally, the EOI generated by local APIC for level trigger interrupt
> contains vector number. The IOAPIC will take this vector number and
> search the IOAPIC RTE entries for an entry with matching vector number and
> clear the remote IRR bit
On Thu, May 17, 2007 at 05:30:13PM -0700, Eric W. Biederman wrote:
> So why does any of this matter?
>
> My memory says that the ioapic state for sending irqs gets reset when we
> unmask the irq.
No. Atleast not on the platform we have tested.
> If not I expect we can use the mask and edge, unmas
On Thu, May 17, 2007 at 04:58:02PM -0700, Eric W. Biederman wrote:
> In essence this makes sense, and it may be the best work around for
> buggy hardware available. However I am not convinced that the remote
> IRR on ioapics works reliably enough to be used for anything. I
> tested this earlier
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:
> on x86_64 kernel, level triggered irq migration gets initiated in the context
> of that interrupt(after executing the irq handler) and following steps are
> followed to do the irq migration.
>
> 1. mask IOAPIC RTE entry; // write to IOAPIC RTE
>
"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:
> on x86_64 kernel, level triggered irq migration gets initiated in the context
> of that interrupt(after executing the irq handler) and following steps are
> followed to do the irq migration.
>
> 1. mask IOAPIC RTE entry; // write to IOAPIC RTE
>
on x86_64 kernel, level triggered irq migration gets initiated in the context
of that interrupt(after executing the irq handler) and following steps are
followed to do the irq migration.
1. mask IOAPIC RTE entry; // write to IOAPIC RTE
2. EOI; // processor EOI write
3. re
26 matches
Mail list logo
