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