Disable intr_storm_threshold mechanism by default
The ixl.4 manual page has documented that the threshold falsely detects interrupt storms on 40Gbit NICs as long ago as 2015, and we have seen similar false positives with the ioat(4) DMA device (which can push GB/s). For example, synthetic load can be generated with tools/tools/ioat 'ioatcontrol 0 200 8192 1 1000' (allocate 200x8kB buffers, generate an interrupt for each one, and do this for 1000 milliseconds). With storm-detection disabled, the Broadwell-EP version of this device is capable of generating ~350k real interrupts per second. The following historical context comes from jhb@: Originally, the threshold worked around incorrect routing of PCI INTx interrupts on single-CPU systems which would end up in a hard hang during boot. Since the threshold was added, our PCI interrupt routing was improved, most PCI interrupts use edge-triggered MSI instead of level-triggered INTx, and typical systems have multiple CPUs available to service interrupts. On the off chance that the threshold is useful in the future, it remains available as a tunable and sysctl. Reviewed by: jhb Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D20401
This commit is contained in:
parent
fb3bc59600
commit
5d0e829978
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=348255
@ -91,7 +91,7 @@ struct proc *intrproc;
|
||||
|
||||
static MALLOC_DEFINE(M_ITHREAD, "ithread", "Interrupt Threads");
|
||||
|
||||
static int intr_storm_threshold = 1000;
|
||||
static int intr_storm_threshold = 0;
|
||||
SYSCTL_INT(_hw, OID_AUTO, intr_storm_threshold, CTLFLAG_RWTUN,
|
||||
&intr_storm_threshold, 0,
|
||||
"Number of consecutive interrupts before storm protection is enabled");
|
||||
|
Loading…
Reference in New Issue
Block a user