Page MenuHomeFreeBSD

kern/intr: add interrupt counters to intr_isrc
Needs ReviewPublic

Authored by ehem_freebsd_m5p.com on Aug 11 2023, 7:50 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Apr 22, 12:07 PM
Unknown Object (File)
Feb 1 2024, 2:37 AM
Unknown Object (File)
Dec 20 2023, 7:28 AM
Unknown Object (File)
Dec 14 2023, 3:31 AM
Unknown Object (File)
Dec 10 2023, 8:12 PM
Unknown Object (File)
Nov 14 2023, 11:23 AM
Unknown Object (File)
Sep 5 2023, 11:56 PM
Unknown Object (File)
Aug 21 2023, 1:54 PM
Subscribers

Details

Reviewers
mjg
markj
Summary

Maintaining the intrcnt/intrnames variables are causing problems.
Notably INTRNG's interrupt release code is unable to properly release
counters. At this point it seems best to work towards moving the values
elsewhere.

The counters also really belong to the interrupting device, not the
controller. As such they should be in the device-side structure, not
the interrupt controller structure.

Additionally this is an architecture-independent area. This should
increase shared source code by taking over.

Note, the array of counters ensures no two processors modify the same
counter at the same time. IPI and PPI interrupt handlers *never* report
strays, thus there is little danger of collision on the stray counter.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 53052
Build 49943: arc lint + arc unit

Event Timeline

ehem_freebsd_m5p.com created this revision.

This is splitting the counter add commit off the flag add commit. Originally these seemed like a single task, but seems further consideration is needed for the flags.

Unfortunately see D38448 for most comments so far.

I have no direct disagreement with @mjg's wish for such counters to be moved to the per-processor area. Issue is this commit is merely an intermediate step in moving the counters from the giant table of counters to intr_event.

I would hope a future commit could make ie_intrcnt serve as the interrupt counter if the interrupt is uni-processor. Whereas for multi-processor interrupts it could serve as an index into the per-processor area.

Issue is still, that is a topic for a future commit, not this one.