On 01/06/2017 at 08:57 PM, Pratyush Anand wrote:
On Friday 06 January 2017 05:18 PM, Xunlei Pang wrote:
>> why to guess that. If I have not missed anything then it seems that number of
vectors needed by kernel is fixed.
>> From arch/x86/include/asm/irq_vectors.h :
>>
>> vector 128 seems fixed for system call.
>> If we have CONFIG_X86_LOCAL_APIC, then vector 0xef to 0xff are used by kernel.
So, this variance should have fixed value as 1 for !CONFIG_X86_LOCAL_APIC and as 18
otherwise, no? So, may be we can take as 18 for all cases.
> Hmm, I pondered quite a lot here, because it's hard to decide one exact value we
should rely on :-)
>
> Yes, FIRST_EXTERNAL_VECTOR(32) is defined by the x86 architecture, and it is unlikely
to change.
> While FIRST_SYSTEM_VECTOR is assigned by kernel, it may vary for different kernel
versions. e.g.
> the latest kernel version and linux-3.10 have different FIRST_SYSTEM_VECTOR values,
there could
> be more system vectors added in the kernel in the future.
>
> Also there are other rare kernel internal reserved vectors, e.g. 0x80 is reserved for
system call vector.
>
> Additionally, there may be cases that one irq has explicit affinity, then multiple
vectors(one for each cpu)
> are allocated. So I just give a flexible variance, we can't precisely know if it
can boot or not without knowing
> all the details, but if it is above the threshold we selected, kdump has a high
possibility to boot fail.
>
> For example, if we choose threshold 256-32-18-1=205 and a system with 204 external
device interrupts,
> among them there are several(say 6) has 0x3 affinity explicitly set, then it will
consume 6 more vectors in
> total that is 210, so the actual calculated nr_min should be 2 instead of 1.
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.
Regards,
Xunlei
>
> But if you think we played a little too careful with variance 64, I guess 32 should
be good enough, after all
> there is one more cpu added for multiple affinity cases:
> if [ $nr_min -gt 1 ]; then
> nr_min=$(($nr_min + 1))
> nr_min=$(($nr_min + $nr_min % 2))
~Pratyush