Re: MSI interrupts

In article <e4ecfb53ef4f33f10b6d2548d5930159@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:

On Tue, 25 Mar 2025 17:54:42 +0000, Dan Cross wrote:
>

In article <0343529d63f68c76b5e0d227ef6e39dd@www.novabbs.org>,
MitchAlsup1 <mitchalsup@aol.com> wrote:

--------------------------

>
Say you have a critical section (of your description) that was
preceded by an if-statement that was predicted to enter CS, but
1,000 cycles later the branch is resolved to not enter the CS.
{{Branch was dependent on an MMI/O location down the PCIe tree
which is why it took so long to resolve.}}
>
HW Backs the core up so that the RF and all memory locations
contain their original values at the point of the mispredicted
branch.
>
Can thread running on core even tell if you entered CS or not !
>
No, your thread cannot.

>
Again, how is that relevant?  The branch predictor can only
handle speculative execution of so-many instructions.

>
Around 300 at present.
Know of any critical sections that long?

Oh, absolutely.

But that's besides the point.  The point is that software _can_
exceed that limit, even if it's a bad idea to do so; it may not
even be immediately obvious to the programmer, who is most
likely working in a high-level langauge, not assembler.

How will your design accommodate that eventuality?

                                                      Attempts
to perform more instructions than that will stall the pipeline.

>
Obviously.
>

A critical section as defined by software may contain more than
that number of instructions.

>
Sure, its possible.
>
But if DECODE cannot push the entire critical section into the
execution window, then BY DEFINITION, it MUST be able to make
the entire critical section appear as if you never started on
it !!!

So ... what, you just don't execute it?  Always skip over it?
Software needs to ensure serial access to some resource.  That's
what critical sections are for.  Your architecture needs to
support that.

From what I gather, you've said to just eschew the atomic event
stuff and build a traditional lock using those primitives.  But
you have also said that a traditional lock can be silently
unlocked if the thread holding it (which, apparently, is an
abstraction known to hardware) is preempted.  It will be like
the lock had never been acquired.

But here's the impedence mismatch: it appears that that happens
_after_ software has already made a decision based on something
that is rolled back later.  If that's mistaken, then say so, but
if not, then the scheme is fatally flawed: there is literally no
way you can use it reliably to build anything that doesn't fit
into your atomic window.

IP gets backed up as if you never entered CS
RF gets backed up as if you never entered CS
LOCK variable never got written to SNOOPable cache where others can see
it
Cache memory gets put back in the "you never got here" states too.
>
[...a lot of the same stuff, repeated over and over snipped]
>

                              A critical section, as defined by
software, may touch more cache lines than your atomic event
proposal can handle.

>
Sure, but then you would only be using my ATOMICs for locking/
unlocking not for the work going on.

Indeed; that's what I've been saying.

But you also seem to imply that if a higher priority interrupt
comes along and preempts the code that's in the critical section
it will silently unlock the lock that is used to serialize entry
into the critical section.  Is that correct?  If so, do you see
how that makes the whole facility useless for building robust
mutual exclusion primitives?  A lock that is silently released
because something else comes along and wants a turn instead is
no lock at all.

                      Thus, for your architecture to be useful,
you must provide some mechanism for handling those
eventualities.

>
As stated about 15 responses ago, just use them as ATOMIC primitive
generators.

Yes.  Was that the same response where you said the lock would
be silently released if a higher-priority interrupt came along?

Your stuff sounds fine for getting into the critsec; but it
doesn't help you once you're in it, and it seems like it may
hurt you if some higher-priority thing comes along and yanks
your lock out from under you.

>
I conceded that point at least 2 days ago.

Ok, now we're back to the question then: what purpose does it
serve?  It doesn't seem like it can be usefully applied to
anything other than building traditional mutexes based on spin
locks, and even then I'm not sure if that's correct (see above).

- Dan C.