Deutsch English Français Italiano |
<vrqa4u$3ktca$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> Newsgroups: comp.arch Subject: Re: MSI interrupts Date: Sun, 23 Mar 2025 17:48:29 -0700 Organization: A noiseless patient Spider Lines: 67 Message-ID: <vrqa4u$3ktca$1@dont-email.me> References: <vqto79$335c6$1@dont-email.me> <36b8c18d145cdcd673713b7074cce6c3@www.novabbs.org> <vreisc$dqb$1@reader1.panix.com> <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org> <vrh2u1$8vn$2@reader1.panix.com> <536efe4d9fd254ac1dfd37f9d9a43838@www.novabbs.org> <utWDP.1370783$TBhc.860098@fx16.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Mon, 24 Mar 2025 01:48:31 +0100 (CET) Injection-Info: dont-email.me; posting-host="134859492fb1e605dc9ff2cb841b4e25"; logging-data="3831178"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Eaoy/KH2OZDZQkTQL2zgW/mDVijdPHNQ=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:8/vQ7Z3qYZq/ZdReR4wzXk1NNRM= In-Reply-To: <utWDP.1370783$TBhc.860098@fx16.iad> Content-Language: en-US Bytes: 4468 On 3/23/2025 9:16 AM, EricP wrote: > MitchAlsup1 wrote: >> On Thu, 20 Mar 2025 12:50:09 +0000, Dan Cross wrote: >> >>> In article <19ad12aadf9a22b760487418c871b3c6@www.novabbs.org>, >>> MitchAlsup1 <mitchalsup@aol.com> wrote: >>> >>> But let me turn it around, what real-world problem does this >>> interrupt prioritization scheme solve coupled with the inability >>> to disable interrupts solve? >> >> The OS does not have to "walk" its schedule queues in order to >> context switch. >> >> The SVR (SuperVisor Return) instruction checks the priority of >> the thread that had been interrupted, and if it is of lower >> priority than what is pending in the interrupt table, the >> one on the interrupt table receives control while the lower >> priority thread remains interrupted. >> >> Thus, the return path from an ISR, just does an SVR. If a >> DPC/softIRQ has been setup, or another interrupt has become >> pending, HW chooses the path--acting as if HW returned control >> to the interrupted thread, and then immediately took the inter- >> rupt of highest priority still pending--without having executed >> a single instruction in the interrupted thread. >> >>> Is anyone complaining that the >>> ability to disable interrupts is somehow a serious burden? >> >> This thread started with the notion of MSI interrupts and the >> inherent need to DI upon arrival at ISR dispatcher. This sub- >> thread is investigating whether one can perform ISRs without >> disabling interrupts. Thus, making IDisablement an unnecessary >> part of interrupt servicing itself. >> >> Your (and EricP)'s contribution is to annotate those instances >> where one can arrive at an ISR IE and still want/need to DI and EI >> independent of the control transfer from and back to interrupted >> thread (even if control arrives reentrantly from interrupted thread). > > Supervisor return, whatever it is called - sysret, rei, svr - > is traditionally another point where a number of OS race conditions > can force it to briefly disable interrupts. > > The classic case is when a DPC/SoftIrq may be posted by an Interrupt > Service Routine (ISR) and causes the First Level Interrupt Handler (FLIH), > which is the ISR nested first on the stack of priority interrupts, > to exit into the OS rather than return to its prior thread. > > The race condition occurs between the point when the FLIH ISR epilogue > checks for pending a pending DPC, and not finding one decides to return > to the prior thread. Between that check and the SVR instruction a higher > priority interrupt occurs and posts a DPC. > > Another race condition can be how does an epilogue know if it is a FLIH > or nested one? A counter for each core incremented by the ISR prologue > and checked by the epilogue would do but what if the nested interrupt > catches a lower level prologue just before it increments the counter. [...] Fun with race conditions... check out some of this shit: https://groups.google.com/g/comp.lang.c++/c/7u_rLgQe86k/m/fYU9SnuAFQAJ ;^D