Path: ...!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Thu, 20 Mar 2025 12:50:09 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vrh2u1$8vn$2@reader1.panix.com>
References: <vqto79$335c6$1@dont-email.me> <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org> <vreisc$dqb$1@reader1.panix.com> <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>
Injection-Date: Thu, 20 Mar 2025 12:50:09 -0000 (UTC)
Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="9207"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 3223
Lines: 60

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.