Re: Remove data dependency barrier from atomic_load_*

2022-03-17 Thread Alexander Bluhm
On Thu, Mar 17, 2022 at 07:12:16AM +, Visa Hankala wrote: > On Wed, Mar 16, 2022 at 11:09:12PM +0100, Alexander Bluhm wrote: > > On Tue, Mar 15, 2022 at 09:15:34AM +, Visa Hankala wrote: > > > However, some DEC Alpha CPUs have their data caches divided into cache > > > banks to improve

Re: Remove data dependency barrier from atomic_load_*

2022-03-17 Thread Visa Hankala
On Wed, Mar 16, 2022 at 11:09:12PM +0100, Alexander Bluhm wrote: > On Tue, Mar 15, 2022 at 09:15:34AM +, Visa Hankala wrote: > > However, some DEC Alpha CPUs have their data caches divided into cache > > banks to improve bandwidth. These cache banks are relatively > > independent. The system

Re: Remove data dependency barrier from atomic_load_*

2022-03-16 Thread Alexander Bluhm
On Tue, Mar 15, 2022 at 09:15:34AM +, Visa Hankala wrote: > However, some DEC Alpha CPUs have their data caches divided into cache > banks to improve bandwidth. These cache banks are relatively > independent. The system maintains coherency, but bus contention can > delay propagation of cache

Remove data dependency barrier from atomic_load_*

2022-03-15 Thread Visa Hankala
This removes the data dependency consumer barrier from the atomic_load_* functions. I think the intent was to keep these functions relaxed in terms of CPU memory order. This makes these functions more agreeable in code that assertions may use, such as the suggested refcnt_read(). Removing the