Page MenuHomeFreeBSD

make maximum interrupt number tunable on ARM, ARM64, MIPS, and RISC-V
ClosedPublic

Authored by gonzo on Dec 30 2020, 7:02 AM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 17 2024, 4:25 AM
Unknown Object (File)
Dec 23 2023, 1:06 AM
Unknown Object (File)
Dec 20 2023, 6:09 AM
Unknown Object (File)
Dec 14 2023, 8:59 AM
Unknown Object (File)
Dec 11 2023, 4:35 AM
Unknown Object (File)
Oct 12 2023, 12:14 AM
Unknown Object (File)
Sep 25 2023, 12:46 PM
Unknown Object (File)
Sep 5 2023, 11:57 PM

Details

Summary

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 36159
Build 33048: arc lint + arc unit

Event Timeline

gonzo requested review of this revision.Dec 30 2020, 7:02 AM
sys/kern/subr_intr.c
146–147

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.

151

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?

411

Is there a reason to use irq_sources_count rather than just machdep_nirq?

1734

Could push M_WAITOK to the next line if it becomes too long.

gonzo added inline comments.
sys/kern/subr_intr.c
146–147

Fixed the constant. I'd like to leave mp_ncpus for another round of changes.

151

Fixed

411

Just an automatic renaming. Fixed.

gonzo marked 3 inline comments as done.
  • Address mhorne's comments

A couple of small nitpicks, otherwise LGTM.

sys/kern/subr_intr.c
186

You can drop the extra newline.

411

Thanks, but it looks like irq_sources_count can be dropped altogether in favor of machdep_nirq.

This revision is now accepted and ready to land.Jan 13 2021, 8:04 PM

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.