Sujet : Re: MSI interrupts
De : cross (at) *nospam* spitfire.i.gajendra.net (Dan Cross)
Groupes : comp.archDate : 20. Mar 2025, 13:50:09
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vrh2u1$8vn$2@reader1.panix.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
In article <19ad12aadf9a22b760487418c871b3c6@
www.novabbs.org>,
MitchAlsup1 <
mitchalsup@aol.com> wrote:
On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote:
>
In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:
I want to address the elephant in the room::
>
Why disable interrupts AT ALL !!
>
So that you can have some mechanism for building critical
sections that span multiple instructions, where just having
access to atomics and spin locks isn't enough.
>
For what kinds of activities are these critical sections ??
Perhaps modifying the interrupt handlers themselves. Maybe
resetting a stack. If you know that you're not in a place where
you can reasonably save the state associated with taking an
interrupt, you should disable interrupts.
For example, I can schedule a DPC/sofIRQ without using a critical
section (and so can even user threads without privilege, given
the MMU allows). So, we need to dive through the "rest of the
available mechanics" -- keyword available !
For that one case. Perhaps there are others where a DPC-style
mechanism (not mechanic) is not appropriate.
There are mechanisms available that readers may not be aware of
or quite grasp how a feature can be used.
Indeed.
So it comes back to:: For what kinds of activities are these
critical sections ?? We know about DPC/softIRQs, we know
about atomic events around core scheduling, and inter-{thread,
process, core} communication. Others ?
Booting the system, before interrupt handlers have been
established.
When running at any privilege, do you not want to accept an interrupt
at higher priority with as little delay as possible ??
>
Usually the assumption is that the critical section is short; a
handful of instructions, perhaps, so that the cost of blocking a
high priority interrupt is low.
>
I think you are talking about critical sections that are not allowed
to fail or be interfered with:: Yes ?
Yup.
But let me turn it around, what real-world problem does this
interrupt prioritization scheme solve coupled with the inability
to disable interrupts solve? Is anyone complaining that the
ability to disable interrupts is somehow a serious burden?
- Dan C.