Sujet : Re: MSI interrupts
De : cross (at) *nospam* spitfire.i.gajendra.net (Dan Cross)
Groupes : comp.archDate : 26. Mar 2025, 05:40:43
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vs00gb$f3$1@reader1.panix.com>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
In article <jwv34f0o75h.fsf-monnier+
comp.arch@gnu.org>,
Stefan Monnier <
monnier@iro.umontreal.ca> 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).
Ah, thanks, Stefan. That makes more sense.
Perhaps some day there will be hardware and systems software and
we can see how it actually works out in practice. I remain
skeptical given the example code that was posted, and it appears
that the claims are still just that: claims.
Regardless, if anyone has the sort of track record to
demonstrate that they can pull it off on the hardware side,
Alsup certainly does, so maybe my skepticism is overly
pessimistic and unwarranted.
- Dan C.
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.