On 01/09/2017 at 02:50 PM, Pratyush Anand wrote:
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?
To be exact, when drivers allocate linux irq(with a cpumask), it will associate the x86
vectors, it's the place where can fail.
As an example, dmar_set_interrupt() --> dmar_alloc_hwirq() --> parent irq domain
alloc -> x86_vector_domain_ops::x86_vector_alloc_irqs()
The dmar_alloc_hwirq() could fail when facing x86 vector pressure