Hi Xunlei,
On Friday 06 January 2017 06:41 PM, Xunlei Pang wrote:
I am not sure, how does explicit affinity work. Does not an affinity 0x03 means that interrupt can be routed to *either* cpu0 or cpu1? Now suppose all the irq
Yes, 0x3 means routing to either cpu0 or cpu1.
line of cpu0 has been occupied and we request a new interrupt with affinity 0x03, would not that be routed to cpu2? If that can be routed then probably we do not need to take this factor in account while calculating minimum number of CPUs.
The vector is allocated when requesting irq or setting the irq affinity, if it finds cpu0 runs out of vectors, the call path(request_irq, set_affinity) will return some error code.
I do not have much issue with any value for keeping the variance, its better to be "safe minimal" than keeping the "best minimal".
However, I would still like to understand this concept. What I understand is that requesting a vector and setting affinity are two mutually exclusive action. Requesting a vector is binding a physical/virtual irq line with the driver (irq handler). set_affinity() will program interrupt controller to raise that irq to all possible CPU when hardware generates that interrupt. Moreover, see kernel/irq/manage.c:__setup_irq(). It does not check return value of set_affinity(). So, __setup_irq() should pass even when set_affinity() fails, and in that case irq will be raised to the cpu as per hardware default affinity settings, no?
~Pratyush