In message
<954433d5-a1fa-466e-bc47-4764b361952d@[EMAIL PROTECTED]
>,
Stargazer <spamtrap@[EMAIL PROTECTED]
> wrote:
> On Mar 17, 8:44 pm, Cyril Novikov <spamt...@[EMAIL PROTECTED]
> wrote:
>> Stargazer wrote:
>> > ; Acknowledge interupt with PIC(s).
>> > ; After calling callbacks, to enable nesting of interrupt handlers
>> > according to priorities
>> > ; TODO: check rotation priorities of 8259 and other options
>> > ;
>> > mov al, CMD_EOI
>> > out PIC_MASTER, al
>> > cmp ebx, 8
>> > jb fin
>> > out PIC_SLAVE, al
>>
>> These 2 OUT's are what takes 2000+ cycles. The reason you see it
>> elsewhere is most likely a bug in your measurement code.
>
> Why would it take 2000+ cycles? interrupt controller is integrated in
> a chipset which provides pretty fast access.
8259 is a legacy interupt controller interface, APIC is the modern
standard.
> Anyway, your assertion is
> not true: if I just comment out the "inc dword [_running_irq]", I get
> total latency of about 300 cycles.
But modern processors execute instructions out of the order specified in
the
program! It is quite possible that the out instructions have not completed
execution when the second rdtsc executes, unless the "inc dword
[_running_irq]" is there.
If this is on a multi-processor machine cacheline ping-pong is a possible
cause.
|
