> I'd like to have the self-IPI part, but I would _really_ really prefer to
> not have the counter, until somebody convices me that it has to be there
for shared PCI devices (where multiple devices are hanging on the
per-hardirq action->next list) it makes sense. (i've tried to explain
these scenarios in one of my previous mails, Message-ID:
<Pine.LNX.3.96.980426183423.32632A-100000@chiara.csoma.elte.hu>)
i aggree that those shadowy APIC races are not a good reason for counters.
I do not have good arguments, other than i tried my best to serialize
dis/enable_irq() and IRQ handler execution, but even with _insane_
timeouts it sometimes happens that we get an 'unexpected' APIC message.
The problem is probably this: the APIC protocol is a multi-step,
checksummed network, which isnt well integrated into the IO-APIC's
external API. Ie. an already posted APIC message _will_ be sent to a CPU
if it's over a certain 'point of no return'. Nothing helps, not masking
off the IRQ in the IO-APIC and no other stuff. It _will_ be sent to the
destination CPU. So, whatever i tried, i _got_ 'spurious' IRQs (we should
rather call them 'late' IRQs), and i was unable to get a clean IRQ
behavior without the counters.
the shared PCI issue is a legitimate answer. It doesnt justify 'unlimited
depth' counters, only to a fixed depth. But we have to have a counter ...
it's easy. Theoretically the current code should never go beyond 'events
== 1', just put some logging code there. If you can somehow achieve that
it never goes beyond 1 then bingo, no need for counters. I have tried hard
and i failed.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu