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)
Sat, May 4, 5:45 PM
Unknown Object (File)
Sat, May 4, 12:09 AM
Unknown Object (File)
Wed, May 1, 7:09 PM
Unknown Object (File)
Mon, Apr 29, 3:34 AM
Unknown Object (File)
Sun, Apr 28, 9:54 AM
Unknown Object (File)
Sat, Apr 27, 5:53 PM
Unknown Object (File)
Wed, Apr 24, 6:21 PM
Unknown Object (File)
Sun, Apr 21, 5:16 AM

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.