Sujet : Re: arm ldxr/stxr vs cas
De : chris.m.thomasson.1 (at) *nospam* gmail.com (Chris M. Thomasson)
Groupes : comp.archDate : 08. Sep 2024, 21:31:49
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vbl1jk$22022$4@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : Mozilla Thunderbird
On 9/8/2024 11:32 AM, Scott Lurndal wrote:
Michael S <already5chosen@yahoo.com> writes:
On Sun, 08 Sep 2024 16:10:41 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
>
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
On 9/7/2024 5:59 PM, MitchAlsup1 wrote:
On Sat, 7 Sep 2024 23:16:35 +0000, Chris M. Thomasson wrote:
>
Thus, it seems reasonable to fail a CAS when one cannot determine
if the memory location has been changed and changed back in the
mean time.
>
I think Scott Lurndal mentioned something about CAS or something on
windows that will assert the bus lock after a lot of failures...
>
On AMD processors (and likely intel), if a core cannot acquire
a cache line in a a finite time, the core will assert the bus lock
to ensure forward progress.
>
Nothing to do with the operating software; purely a hardware thing.
>
>
I think, on AMD processors made in this century the only cases that
resort to physical bus lock are
A) atomic accesses that cross cache boundary
B) atomic accesses that address non-cached memory regions
C) A core cannot acquire a cache line in a finite time. We
encountered this in 2010 on AMD Opteron processors with
our HyperTransport connected CXL-like chip (designed in 2005);
r/t latency could be as high as 800ns to remote memory.
Yup. That's what you reported to me. Thanks for that Scott.