Use a machdep.nirq tunable intead of compile-time constant NIRQ
as a value for maximum number of interrupts. It allows keep a system
footprint small by default with an option to increase the limit
for large systems like server-grade ARM64
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 35787 Build 32676: arc lint + arc unit
Event Timeline
sys/kern/subr_intr.c | ||
---|---|---|
152 | Since we are now sizing this dynamically, it would make more sense to do it based on mp_ncpus. You might also drop this constant and just inline it in intr_irq_init(), since it is not used elsewhere. | |
157 | machdep_ is an unusual prefix for a variable --- I don't think anything else is named that way. Maybe intr_nirq if not just nirq? | |
410 | Is there a reason to use irq_sources_count rather than just machdep_nirq? | |
1733 | Could push M_WAITOK to the next line if it becomes too long. |
FYI, I believe that this commit broke the kernel on MIPS64, at least via qemu: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253051
This is rather a bit overdue, but I note D27844 has a troublesome interaction with D16861. At fd036deac169, vmstat was modified to look for nintrcnt to distinguish kernel core dumps in which intrcnt/intrnames were arrays versus pointers. As a result right now if an ARM[64]/RISC-V kernel core dump was analyzed using vmstat the interrupt counts will be misinterpreted since it will expect an array instead of a pointer.
I had been pondering renaming intrcnt_count to nintrcnt as part of D38305, but had decided that was unnecessary. Yet now noticing this concern I'm wonder whether I should bring that back due to this issue.