Re: [patch] x86, apic: use 0x20 for the IRQ_MOVE_CLEANUP_VECTOR instead of 0x1f

[Eric W. Biederman]

"H. Peter Anvin" <hpa@xxxxxxxxx> writes:

> On 01/11/2010 05:52 PM, Eric W. Biederman wrote:
>> 
>> After having the documentation quoted at me.  I am having a distinct
>> memory of one piece of documentation saying:
>> "interrupts within a priority level can be delivered in any order"
>> 
>> So I am guessing there is not any ordering of interrupts in the same
>> priority level until they get to the local apic.
>> 
>
> There is no ordering of interrupts before they hit the local APIC, since
> the local APIC is what would serialize them...

The two wire bus that the all came across would serialize them.
I'm not certain how much of that was preserved with front-side
bus delivery.

>
>> What guarantee we need is the interesting question.
>> 
>> The cleanup ipi is sent when we have seen an interrupt arrive at it's
>> newly configured location.  It is possible that there is still an
>> interrupt in flight to the old configured location (think NUMA where
>> the interrupt has been migrated from off node to on node).  We want
>> the guarantee that the ipi arrives after the inflight irq.  Which
>> means on the wire ordering as well as in the local apic ordering is
>> interesting.
>
> I don't think there is any such guarantee possible, but that that has
> nothing to do with the interrupt priority.  Suresh tells me that that is
> handled by detecting and re-posting the migration IRQ.

The re-posting should only be for the case where we are migrating more
than one irq at a time.


>> I am slammed with other stuff right now so I don't think I will have
>> time to find the old documentation I was looking at for a couple of
>> more days.
>
> I'm wondering if what you're thinking of are the really old LAPICs which
> could only remember two pending interrupts per priority level?

Not precisely, but it could easily be something similar.


Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/