On 25/05/16 11:52, Alex Bennée wrote:
> Sergey Fedorov writes:
>
>> On 24/05/16 22:56, Emilio G. Cota wrote:
>>> On Tue, May 24, 2016 at 09:08:01 +0200, Paolo Bonzini wrote:
On 23/05/2016 19:09, Emilio G. Cota wrote:
> PS. And really equating smp_wmb/rmb to release/acquire as we have unde
Sergey Fedorov writes:
> On 24/05/16 22:56, Emilio G. Cota wrote:
>> On Tue, May 24, 2016 at 09:08:01 +0200, Paolo Bonzini wrote:
>>> On 23/05/2016 19:09, Emilio G. Cota wrote:
PS. And really equating smp_wmb/rmb to release/acquire as we have under
#ifdef __ATOMIC is hard to justify, o
On 24/05/16 22:56, Emilio G. Cota wrote:
> On Tue, May 24, 2016 at 09:08:01 +0200, Paolo Bonzini wrote:
>> On 23/05/2016 19:09, Emilio G. Cota wrote:
>>> PS. And really equating smp_wmb/rmb to release/acquire as we have under
>>> #ifdef __ATOMIC is hard to justify, other than to please tsan.
>> Tha
On Tue, May 24, 2016 at 09:08:01 +0200, Paolo Bonzini wrote:
> On 23/05/2016 19:09, Emilio G. Cota wrote:
> > PS. And really equating smp_wmb/rmb to release/acquire as we have under
> > #ifdef __ATOMIC is hard to justify, other than to please tsan.
>
> That only makes a difference on arm64, right?
On Sun, May 22, 2016 at 08:58:51 +0100, Alex Bennée wrote:
> For tsan runs you need to re-build with:
>
> ./configure --cc=gcc --extra-cflags="-pie -fPIE -fsanitize=thread"
> --with-coroutine=gthread
>
> Specifically the coroutine ucontext messing really confuses TSAN.
With your configure arg
On 23/05/2016 19:09, Emilio G. Cota wrote:
> E.
>
> PS. And really equating smp_wmb/rmb to release/acquire as we have under
> #ifdef __ATOMIC is hard to justify, other than to please tsan.
That only makes a difference on arm64, right?
acquire release rmb
On Mon, May 23, 2016 at 09:53:00 -0700, Richard Henderson wrote:
> On 05/21/2016 01:42 PM, Emilio G. Cota wrote:
> >In the process, the atomic_rcu_read/set were converted to implement
> >consume/release semantics, respectively. This is inefficient; for
> >correctness and maximum performance we only
On 05/21/2016 01:42 PM, Emilio G. Cota wrote:
In the process, the atomic_rcu_read/set were converted to implement
consume/release semantics, respectively. This is inefficient; for
correctness and maximum performance we only need an smp_barrier_depends
for reads, and an smp_wmb for writes. Fix it
On Mon, May 23, 2016 at 16:21:36 +0200, Paolo Bonzini wrote:
> On 21/05/2016 22:42, Emilio G. Cota wrote:
> > Commit a0aa44b4 ("include/qemu/atomic.h: default to __atomic functions")
> > set all atomics to default (on recent GCC versions) to __atomic primitives.
> >
> > In the process, the atomic_
On 21/05/2016 22:42, Emilio G. Cota wrote:
> Commit a0aa44b4 ("include/qemu/atomic.h: default to __atomic functions")
> set all atomics to default (on recent GCC versions) to __atomic primitives.
>
> In the process, the atomic_rcu_read/set were converted to implement
> consume/release semantics,
Emilio G. Cota writes:
> Commit a0aa44b4 ("include/qemu/atomic.h: default to __atomic functions")
> set all atomics to default (on recent GCC versions) to __atomic primitives.
>
> In the process, the atomic_rcu_read/set were converted to implement
> consume/release semantics, respectively. This
Commit a0aa44b4 ("include/qemu/atomic.h: default to __atomic functions")
set all atomics to default (on recent GCC versions) to __atomic primitives.
In the process, the atomic_rcu_read/set were converted to implement
consume/release semantics, respectively. This is inefficient; for
correctness and
12 matches
Mail list logo
