Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: "Chris M. Thomasson" Newsgroups: comp.arch Subject: Re: Arm ldaxr / stxr loop question Date: Wed, 13 Nov 2024 01:23:51 -0800 Organization: A noiseless patient Spider Lines: 37 Message-ID: References: <3lGdnVvGQIAq2676nZ2dnZfqnPGdnZ2d@supernews.com> <0TmdnaP6ecXoQ676nZ2dnZfqn_adnZ2d@supernews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 13 Nov 2024 10:23:52 +0100 (CET) Injection-Info: dont-email.me; posting-host="6a1ff3e9645d38e0c84409251fc3c409"; logging-data="2252042"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bjNc4hQSUo+djzyc4MUB2P+U4VY0bQoc=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:oQKevnc1rU+56D4ussBhUlBrIFU= Content-Language: en-US In-Reply-To: Bytes: 3092 On 11/12/2024 5:50 PM, Chris M. Thomasson wrote: > On 11/12/2024 3:02 PM, aph@littlepinkcloud.invalid wrote: >> Chris M. Thomasson wrote: >>> On 11/12/2024 4:14 AM, aph@littlepinkcloud.invalid wrote: >>>> >>>> One other thing to be aware of is that the StoreLoad barrier needed >>>> for sequential consistency is logically part of an LDAR, not part of a >>>> STLR. This is an optimization, because the purpose of a StoreLoad in >>>> that situation is to prevent you from seeing your own stores to a >>>> location before everyone else sees them. >>> >>> Fwiw, even x86/x64 needs StoreLoad when an algorithm depends on a >>> store followed by a load to another location to hold. LoadStore is >>> not strong enough. The SMR algorithm needs that. Iirc, Peterson's >>> algorithms needs it as well. >> >> That's right, but my point about LDAR on AArch64 is that you can get >> sequential consistency without needing a StoreLoad. Very interesting... Need to ponder on this. Still running it using no memory barrier via a RCU based algorithm has to be faster. Humm... Membar free reads is very nice. >> LDAR can peek >> inside the store buffer and, much of the time, determine that it isn't >> necessary to do a flush. I don't know if Arm were the first to do >> this, but I don't recall seeing it before. It is a brilliant idea. > > Iirc, a sequential membar was strange on SPARC. I have seen things like > this before wrt RMO mode: > > membar #StoreLoad | #LoadStore | #LoadLoad | #StoreStore > > shit. It's been a while! damn.