Question about rescan condition

[Neil Horman]

On Thu, Jul 28, 2016 at 02:15:48PM +0800, Yun Wu (Abel) wrote:
> 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
> 
> 
> 

Yeah, you look to be right.  My first thought is to be heavy handed and use the
listening interface on libudev to detect hotplug events, and just set
need_rescan, anytime we get one. 

Thoughts?
Neil