For some devices, all that you
can do is to poll, and sometimes what you
need to do ... is poll. If "eight identical devices" are rigged on just one board, it may well raise the interrupt just one time to signal that one-or-more of the devices need attention. If they are separate boards all sharing the same IRQ, then if you can "poll" all of them and thus avoid "X" consecutive interrupts, you also come out ahead. Even though interrupts happen constantly, they
are disruptive to the processor's attempts at pipelining .. which is where modern processors get their phenomenal rated speeds. Once you find yourself
in a first-level interrupt handler, "you're there, make the most of it."
An interrupt-handler is not necessarily the time to try to be "efficient." Interrupts are not like software signals. What you need to think of, instead, is being
thorough. Make sure that an interrupt does not wander by, trying to tell you something, and you "efficiently" don't notice.
You
also need to consider that perhaps the interrupt does not belong to you at all. It may belong to another device, unrelated to yours.
Or, by some unhappy luck of the draw, the interrupts could pile-up so that both your device
and another device have signaled for attention at precisely the same nano-bleem, so that the interrupt is for (or can be treated as) both your device
and someone else's, at the same time. It can get strange. You can never predict it. That's why you need to be conservative. And in any case, the time that you spend inside the routine is a lot less costly than the time the kernel and the CPU have already spent in getting you there.
The only purpose of the "upper half" (initial interrupt-response) processing should be to
notice what needs to be done and queue-up the appropriate "lower half" routines to actually do the work... then get out and let the next upper-half routine do
its thing. But you will come out ahead if you happen to detect that several identical devices
all need servicing and can, by polling their status-registers, stop them from
all generating (consecutive, redundant) interrupts.