search for: __atomic_thread_fence

...> also think that risks unexpected coherence miss problems, though they would >> probably be very rare. But they would be very surprising if they did occur. >> > > Today's LLVM already emits 'lock or %eax, (%esp)' for 'fence > seq_cst'/__sync_synchronize/__atomic_thread_fence(__ATOMIC_SEQ_CST) when > targeting 32-bit x86 machines which do not support mfence. What > instruction sequence should we be using instead? > Do they have non-temporal accesses in the ISA? On Wed, Jan 13, 2016 at 10:59 AM, Tim Northover <t.p.northover at gmail.com> >> wrote...

...ng used index acquires a ring entry from host - updating the available index releases it to host Thus when using weak barriers and building for SMP (as most people do), smp_load_acquire and smp_store_release will do exactly the right thing to synchronize with the host. In fact, QEMU already uses __atomic_thread_fence(__ATOMIC_ACQUIRE) and __atomic_thread_fence(__ATOMIC_RELEASE); Documentation/circular-buffers.txt suggests smp_load_acquire and smp_store_release for head and tail updates. Since we have to worry about UP and strong barrier users, let's add APIs to wrap these, and use in virtio_ring.c It is t...

...ng used index acquires a ring entry from host - updating the available index releases it to host Thus when using weak barriers and building for SMP (as most people do), smp_load_acquire and smp_store_release will do exactly the right thing to synchronize with the host. In fact, QEMU already uses __atomic_thread_fence(__ATOMIC_ACQUIRE) and __atomic_thread_fence(__ATOMIC_RELEASE); Documentation/circular-buffers.txt suggests smp_load_acquire and smp_store_release for head and tail updates. Since we have to worry about UP and strong barrier users, let's add APIs to wrap these, and use in virtio_ring.c It is t...

...herence miss problems, though they would >>>> probably be very rare. But they would be very surprising if they did occur. >>>> >>> >>> Today's LLVM already emits 'lock or %eax, (%esp)' for 'fence >>> seq_cst'/__sync_synchronize/__atomic_thread_fence(__ATOMIC_SEQ_CST) when >>> targeting 32-bit x86 machines which do not support mfence. What >>> instruction sequence should we be using instead? >>> >> >> Do they have non-temporal accesses in the ISA? >> > > I thought not but there appear to be in...

I agree with Tim's assessment for ARM. That's interesting; I wasn't previously aware of that instruction. My understanding is that Alpha would have the same problem for normal loads. I'm all in favor of more systematic handling of the fences associated with x86 non-temporal accesses. AFAICT, nontemporal loads and stores seem to have different fencing rules on x86, none of them

...g __ATOMIC_SEQ_CST since gcc docs say they are only synchronized + * with other __ATOMIC_SEQ_CST calls. + */ +#define smp_mb() __sync_synchronize() + +/* + * This abuses the atomic builtins for thread fences, and + * adds a compiler barrier. + */ +#define smp_release() do { \ + barrier(); \ + __atomic_thread_fence(__ATOMIC_RELEASE); \ +} while (0) + +#define smp_acquire() do { \ + __atomic_thread_fence(__ATOMIC_ACQUIRE); \ + barrier(); \ +} while (0) + +#endif diff --git a/tools/virtio/ringtest/main.c b/tools/virtio/ringtest/main.c new file mode 100644 index 0000000..3a5ff43 --- /dev/null +++ b/tools/v...

...g __ATOMIC_SEQ_CST since gcc docs say they are only synchronized + * with other __ATOMIC_SEQ_CST calls. + */ +#define smp_mb() __sync_synchronize() + +/* + * This abuses the atomic builtins for thread fences, and + * adds a compiler barrier. + */ +#define smp_release() do { \ + barrier(); \ + __atomic_thread_fence(__ATOMIC_RELEASE); \ +} while (0) + +#define smp_acquire() do { \ + __atomic_thread_fence(__ATOMIC_ACQUIRE); \ + barrier(); \ +} while (0) + +#endif diff --git a/tools/virtio/ringtest/main.c b/tools/virtio/ringtest/main.c new file mode 100644 index 0000000..3a5ff43 --- /dev/null +++ b/tools/v...

...be very > rare. But they would be very surprising if they > did occur. > > > Today's LLVM already emits 'lock or %eax, (%esp)' for > 'fence > seq_cst'/__sync_synchronize/__atomic_thread_fence(__ATOMIC_SEQ_CST) > when targeting 32-bit x86 machines which do not > support mfence. What instruction sequence should we > be using instead? > > > Do they have non-temporal accesses in the ISA? > > > I...

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't