Sujet : Re: MSI interrupts
De : monnier (at) *nospam* iro.umontreal.ca (Stefan Monnier)
Groupes : comp.archDate : 26. Mar 2025, 03:58:08
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <jwv34f0o75h.fsf-monnier+comp.arch@gnu.org>
References : 1 2 3 4 5
User-Agent : Gnus/5.13 (Gnus v5.13)
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.
Stefan