Sujet : Re: MSI interrupts
De : mitchalsup (at) *nospam* aol.com (MitchAlsup1)
Groupes : comp.archDate : 20. Mar 2025, 00:28:27
Autres entêtes
Organisation : Rocksolid Light
Message-ID : <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>
References : 1 2 3 4 5
User-Agent : Rocksolid Light
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 ??
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 !
There are mechanisms available that readers may not be aware of
or quite grasp how a feature can be used.
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 ?
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 ?
Does Interrupt Disable help in this goal ??
>
This is predicated on an incomplete view of the situation and
the intersection between hardware and software. Serving high
priority interrupts quickly is not the only consideration.
>
Is there a SANE way to avoid disabling of interrupts ??
>
It depends on your definition of "sane" in this context. One
may imagine redesigning all of a system's locking primitives,
perhaps, to avoid the need to block interrupts in most cases.
But that pushes a lot of complexity onto software for dubious
benefit, and even then, it's not clear to me that they can be
blocked in _all_ cases.
>
- Dan C.