Re: MSI interrupts

On Wed, 26 Mar 2025 2:58:08 +0000, Stefan Monnier wrote:

Even so, I don't see the point of the proposed atomic framework.
It seems to have no significant advantage over a more
traditional scheme; CAS, LL-SC, whatever seem more general and
less intertwined with primitives that the hardware has no real
business injecting itself into (like threads).

>
AFAICT it's somewhat similar to ARM's LL/SC (which can also cover some
number of cache lines) except that it takes care of looping for you: if
the final store fails because of interference My 66000 will "simply"
abort
the whole operation (reusing the speculation hardware) and start over,
instead of having to write an explicit loop.
>
Without actual hardware and software to try it's hard to assess how well
it's going to work, but the design sounds good: it should lead to more
compact code than LL/SC, be more general/friendly to lock-free coding
than T&S/C&S, and also compared to LL/SC it should behave better under
high contention because it is careful to guarantee overall forward
progress (in case of conflict between two cores, at least one of them
can finish successfully).
>
IIRC there's also some kind of mechanism to retry more cleverly, i.e. so
that when N cores are in conflicts, not only one of them succeeds, but
the N-1 remaining cores have a fighting chance of avoiding bumping into
each other next time around.  I don't know the details, tho, and IIUC
this is not automatic: some relevant info is provided but it's up to the
code to do something useful with it.

ESM operates in 3 modes {optimistic, Greedy, Methodological}
In the optimistic mode, core tries to execute the instructions as
if there were no ATOMIC activities and if it succeeds, then these
ATOMIC instructions took no more time than if they were not ATOMIC
at all.
Greedy:: if there is a failure in optimistic mode, the core switches
to Greedy Mode, applies sequential consistency to memory accesses,
and is allowed to NaK lower priority SNOOPs if it has decoded all
the way to the esmLOCKstore(). A second SNOOP to an already SNOOPed
cache line fails the event and switches mode to methodological.
Methodological: When Greedy fails, core switches to Methodological.
The addresses of the participating lines are bundled up into a
message to the system arbitor, who uses a TLB-like structure to
GRANT exclusive access to up to 8 cache lines, returning a message
to core. That message contains a count of cores ahead of this one
in contention. SW can use count to proactively decrease interference.
At the end of the event (both success and fail) the same message
is sent to the arbitor to remove these lines from its grant table.
Grants are en-massé and deGrants are en-massé.
After any success, ESM reverts to Optimistic. SW does not see these
modes in operation.
After any context-switch ESM reverts to Optimistic.
When SW arrives at a fail point, SW can read the WHY register (16-bits)
positive numbers are a count of events in front of this one, negative
numbers are an enumeration of spurious failures, zero is success.

>
        Stefan