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: References: <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org> <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 wrote: >On Wed, 19 Mar 2025 14:03:56 +0000, Dan Cross wrote: > >> In article <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org>, >> MitchAlsup1 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.