Hi Neil et al,
The question comes from commit 93ed801, in which a condition was added to
judge whether irqbalance needs to rescan.
/* IRQ removed and reinserted, need restart or this will
* cause an overflow and IRQ won't be rebalanced again
*/
if (count < info->irq_count) {
need_rescan = 1;
break;
}
This works well for most situations, but not all. During one SLEEP_INTERVAL,
when an IRQ is removed and reinserted like the above comment said, AND the
times of the IRQ being serviced after reinserted do become a larger number
than when unremoved, the IRQ can hardly be rebalanced again. Actually this
problem shows up very occasionally in my recent hotplug tests, but once
happened on performance-critical IRQs, it is undoubtedly a disaster.
This problem can even be worse when the two IRQs, removed one and reinserted
one, belongs to different kind of devices, in which case wrong balance policies
might be used.
To solve this problem, I think we can make efforts in two aspects:
(given the removed IRQ is A and the reinserted one is B)
a) If A != B, set need_rescan to 1. This can be achieved by comparing the
two IRQs' name string.
b) If A == B, we simply treat this as an modification on its affinity. An
unexpected modification on affinity can cause inconsistency between the
IRQ's real affinity and the affinity recorded inside irqbalance's data
structure, leading to inappropriate load calculation.
I haven't yet figured out a proper way to solve the inconsistency, or is there
already a solution that I missed?
Any comments are appreciated.
Thanks,
Abel
