Question about rescan condition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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;

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. 


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux