Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.arch Subject: Re: MSI interrupts Date: Thu, 27 Mar 2025 19:09:14 -0700 Organization: A noiseless patient Spider Lines: 602 Message-ID: References: <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.org> <601781e2c91d42a73526562b419fdf02@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 28 Mar 2025 03:09:17 +0100 (CET) Injection-Info: dont-email.me; posting-host="7ce1f9b3539f865da57caab62bfa1cad"; logging-data="1697969"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/0cqr1e9PAkFbmRdsxo6dUPjHqP8fCVL8=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:quGxYCTjr9ooDBg8MIpxftCxz7I= Content-Language: en-US In-Reply-To: On 3/27/2025 6:01 PM, Dan Cross wrote: > In article <601781e2c91d42a73526562b419fdf02@www.novabbs.org>, > MitchAlsup1 wrote: >> On Thu, 27 Mar 2025 17:19:21 +0000, Dan Cross wrote: >>> In article <7a093bbb356e3bda3782c15ca27e98a7@www.novabbs.org>, >>> MitchAlsup1 wrote: >>>> On Wed, 26 Mar 2025 4:08:57 +0000, Dan Cross wrote: >>>>> [snip] >>>>> 1. `from` may point to a cache line >>>>> 2. `to` may point to a different cache line. >>>>> 3. Does your architecture use a stack? >>>> >>>> No >>> >>> You make multiple references to a stack just below. I >>> understand stack references are excluded from the atomic event, >>> but I asked whether the architecture uses a stack. Does it, or >>> doesn't it? >>> >>>>> What sort of alignment criteria do you impose? >>>> >>>> On the participating data none. On the cache line--cache line. >>> >>> I meant for data on the stack. The point is moot, though, since >>> as you said stack data does not participate in the atomic event. >> >> Stack does not NECESSARILY participate. However, if you perform >> a esmLOCKload( SP[23] ) then that line on the stack is participating. > > Very good. > >>>>> At first blush, it seems to me that >>>>> the pointers `from_next`, `from_prev`, and `to_next` could be >>>>> on the stack and if so, will be on at least one cache line, >>>>> and possibly 2, if the call frame for `MoveElement` spans >>>>> more than one. >>>> >>>> The illustrated code is using 6 participating cache lines. >>>> Where local variables are kept (stack, registers) does not >>>> count against the tally of participating cache lines. >>> >>> Huh. >> >> There are 6 esmLOCKxxxxx() so there are 6 participating lines-- >> and these are absolutely independent from where the variables >> are located. The variables carry information but do not part- >> ticipate they carry data between operations on the particupating >> lines. > > That was clearly in the code. That was not what the "Huh" was > in resposne to. > >>> How would this handle something like an MCS lock, where >>> the lock node may be on a stack, though accessible globally in >>> some virtual address space? >> >> As illustrated above esmLOCKload( SP[23]) will cause a line on >> the stack to participate in the event. > > Ok, good to know. > >> ---------------- >>>>> But later you wrote, >>>>> >>>>>> So, if you want the property whereby the lock disappears on any >>>>>> control transfer out of the event {exception, interrupt, SVC, SVR, ...}; >>>>>> then you want to use my ATOMIC stuff; otherwise, you can use the >>>>>> normal ATOMIC primitives everyone and his brother provide. >>>>> >>>>> Well, what precisely do you mean here when you say, "if you want >>>>> the property whereby the lock disappears on any control transfer >>>>> out of the event"? >>>> >>>> If you want that property--you use the tools at hand. >>>> If you don't just use them as primitive generators. >>> >>> I wasn't clear enough here. I'm asking what, exactly, you mean >>> by this _property_, >> >> The property that if an interrupt (or exception or SVC or SVR) >> prevents executing the event to its conclusion, HW makes the >> event look like it never started. So that when/if control returns >> we have another chance to execute the event as-if ATOMICally. > > Ok. So let's be crystal clear here: after the event concludes > successfully, a subsequent exception, interrupt, or whatever, > will not magically roll back any of the values set and made > visible system-wide as a result of the successful conclusion of > the atomic event. Correct? That's what I've been asking. > >>> not what you mean when you write that one >>> can use these atomic events if one wants the property. That is, >>> I'm asking you to precisely define what it means for a lock to >>> "disappear". >>> >>> It seems clear enough _now_ that once the event concludes >>> successfully the lock value is set to whatever it was set to in >>> during the event, but that wasn't clear to me earlier and I >>> wanted confirmation. >> >> Not "the lock value" but "all participating values" are set >> and become visible system-wide in a single instant. > > Sure. But there was only one participating value in the > spinlock example. ;-} > >> No 3rd >> party sees some set and others remain unset. Everybody sees >> all of then change value between this-clock and its successor. > > Sure. You've said this all along, and I've never disputed it. > >>> In particular, it seems odd to me that one would bother with a >>> lock of some kind during an event if it didn't remain set after >>> the event. >> >> Consider CompareTripleSwapFour() as an atomic primitive. How >> would you program this such that nobody nowhere could ever >> tell that the four updated locations changes in any order >> then simultaneously ??? Without using a LOCK to guard the >> event ??? And without demanding that all four updates are >> to the same cache line ??? >> >> {{Nobody nowhere included ATOMIC-blind DMA requests}} > > The fundamental issue here is that, when I refer to a "lock" I > have been talking about a software mutual exclusion primitive, > and you are referring to something else entirely. > > I would have thought my meaning was clear from context; > evidently not. > >>> If you do all of your critical section stuff inside >>> of the event, and setting the lock in the event is not visible >>> until the event concludes, why bother? If on the other hand you >>> use the event to set the lock, why bother doing additional work >>> inside the event itself, but in this case I definitely don't >>> want something else to come along and just unset the lock on its >>> own, higher priority or not. >> >> It is clear you do not understand the trouble HW takes to implement >> even DCADS where between any 2 clocks, one (or more) SNOOPs can >> take the lines you are DCADSing. It is this property of cache >> coherence that gets in the way of multi-operation ATOMIC events. > > As above, when I refer to "setting the lock" I am referring to > acquiring a mutex; a software primitive. I am not referring to > what the hardware does internally. Consider what I wrote above, > the section that you quoted, in that context. > >> In 2004 Fred Weber came to me and ask: "Why can't we (AMD) give >> Microsoft the DCADS they want. I dug into it, and ASF was my >> solution in x86 ISA, ESM is my solution in RISC-based ISA. It >> removes the need to add ATOMIC primitives to ISA over generations. >> >> It also provides the ability to do other things--which apparently >> you will not use--sort of like complaining that your new car has >> auto-park a feature you will never use. > > "It is clear you do not understand the trouble SW takes to > implement even simple things that are beyond the capability of > hardware." > > (Back at you. I think I've been pretty polite here; I'm getting > tired of the barbs.) > >>>>> What I _hope_ you mean is that if you transfer "out of the >>>>> event" before the `esmLOCKstore` then anything that's been done >>>>> since the "event" started is rolled back, but NOT if control >>>>> transfer happens _after_ the `esmLOCKstore`. If THAT were the >>>>> case, then this entire mechanism is useless. >>>> >>>> One can use a esmLOCKstore( *SP, 0 ) to abandon an event. HW >>>> detects that *SP is not participating in the event, and uses >>>> the lock bit in the instruction to know it is time to leave >>>> the event in the failed manner. No ST is performed to the ========== REMAINDER OF ARTICLE TRUNCATED ==========