On 29/08/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
Dmitry Adamushko wrote:

I think the additional costs of maintaining an error counter are almost
negligible. The test is in the unlikely path, and the first condition
already keeps us away from touching the counter.

But it's updated (unhandled = 0) any time the ISR(s) report something different from XN_ISR_NONE.  Hence, it's at the beginning of the xnintr_t structure, hopefully, at the same cache line with other highly-used members (i.e. isr, cookie and hits).

The benefit of not
kicking out IRQ lines on spurious IRQs is obvious (think of EMC issues,
though one should better solve them on the board...).

Yep, that's why I'm asking whether we really need it or no. If a scenario when "spurious" interrupts indeed happen from time to time and a minor number of them (consequently) is not something completely unacceptable, then we might keep this "unhandled" counter. Here I don't have enough practical experience/evidence and may only rely on the linux way (damn, now I understand why they advised people not to read windows kernel code :)

BTW, is there a difference between unlikely(a && b) and unlikely(a) &&
unlikely(b) that we should care about here?

I had it also in mind and grepped use cases of "unlikely" in kernel/ directory. There are a number of unlikely (a op. b) but none of unlikely(a) op. unlikely (b).

Out of curiosity, one may disassemble code for both cases. My feeling though, unlikely(a && b) is at least not worse (cpu and compiler-wise) but don't want to speculate as I'm quite uneducated bozo here :)


Best regards,
Dmitry Adamushko

Xenomai-core mailing list

Reply via email to