> 1)
> Just for the people interrested in IRQ, there
> is a strange report for SMP bi P II 300 :
> When you produce an IRQ (the line directly goes
> active by hardware), it can be delayed quite a lot:
>
> After udelay(1), the IRQ is still not treated.
> After udelay(10), the IRQ is treated (count is incremented).
>
> The delay does not exists on 386 (few instructions
> before IRQ treatment) and is not seen on a UP PII
> 300 here.
these results are a bit misleading. Could you maybe also save the rdtsc
timestamp for each step? The local APIC is decoupled from the CPU core,
while the 'XT' IRQ handling protocol is implemented in the core CPU, in
microcode. Thus those 10 usecs are not 'lost' with the APIC approach, but
they are completely wasted with the 'XT-PIC' IRQ handling approach. The
latency should be about the same for both, the APIC has to transfer a ~100
bytes message over a 66 MHz 4-line APIC bus, the XT-PIC protocol has to
use ISA cycles to communicate with the 8259A.
(being a multinode network, the APIC-IRQ's latency is a bit more
undeterministic, it can be delayed by noise/resend/arbitration effects
and can be delayed by the state of the local APIC)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu