On 12/20/2016 at 10:49 AM, Pratyush Anand wrote:
On Monday 19 December 2016 08:54 PM, Xunlei Pang wrote:
> # Special treatment for x86_64, in case kdump runs out of vectors.
> + if [ $arch = "x86_64" ]; then
> + nr_arch_min=$(ls /proc/irq/ -l | grep ^d | wc -l)
> + # Estimated minium cpus required by irqs(vectors), we roughly
> + # use 256-32(see kernel FIRST_EXTERNAL_VECTOR)=224 as the max
> + # supported vectors can be allocated to io devices per cpu.
> + nr_arch_min=$(($nr_arch_min + 223))
> + nr_arch_min=$(($nr_arch_min / 224))
> + if [ $nr_arch_min -gt 1 ]; then
> + # The system seems to have tons of irqs, add one more cpu
> + # for further safety.
> + nr_arch_min=$(($nr_arch_min + 1))
> + fi
> +
> + if [ $nr_result -lt $nr_arch_min ]; then
> + nr_result=$nr_arch_min
> + fi
> + fi
> +
I think this is what we need in first place. Rest of the code probably we can leave until
we are sure that a max number of CPU works reliably with all dump options.
OK
In theory, makedumpfile issue can be independent of this one, this patchset is about how
to choose the proper number of kdump cpus safely,
while makedumpfile option is about how to make use of those cpus. But I agree that we
should make progressive steps.
Regards,
Xunlei