Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Wed, 19 Mar 2025 23:28:27 +0000
Organization: Rocksolid Light
Message-ID: <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>
References: <vqto79$335c6$1@dont-email.me> <ohjCP.37185$SVG3.13173@fx42.iad> <vrcqcr$3ddah$1@dont-email.me> <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org> <vreisc$dqb$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="918603"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Site: $2y$10$Pm9SriMxF.wdUFEqf3ubROrsWG.7i/LEZfjVWaY2MGn1ysKlChEvi
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
Bytes: 3227
Lines: 52

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.