Hi,
Now I get back mail from vger, after two day off.
> these results are a bit misleading. Could you maybe also save the
> rdtsc timestamp for each step?
Unfortunately that is not my computer.
> 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.
Thanks for the explanation.
IHMO this may trigger problems with some not-so-tested hardwares:
Before, an external device can raise it interrupt line and then
chances were low that software device driver will send some
new commands before it has treated the interrupt.
With the new APIC, the device driver may send a command without
knowing that the hardware raised its interrupt line - the latency
from the software point of view is far to be null.
Just ideas,
Etienne.
----------- etienne.lorrain@ibm.net
-- hdc: irq timeout: status=0xd0 { Busy }
-- ide1: reset: success
----------> I like Linux !
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu