[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to tri
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy |
Date: |
Mon, 30 Mar 2015 18:04:07 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
* Paolo Bonzini (address@hidden) wrote:
>
>
> On 23/03/2015 03:20, David Gibson wrote:
> >>> 1) There's no barrier after the write, so there's no guarantee
> >>> the other thread will eventually see it (in practice we've got
> >>> other pthread ops we take so we will get a barrier somewhere,
> >>> and most CPUs eventually do propagate the store).
> > Sorry, I should have been clearer. If you need a memory barrier,
> > by all means include a memory barrier. But that should be
> > explicit: atomic set/read operations often include barriers, but
> > it's not obvious which side will include what barrier.
>
> Memory barriers are not needed here. The variable is set
> independently from every other set. There's no ordering.
>
> atomic_read/atomic_set do not provide sequential consistency. That's
> ensured instead by atomic_mb_read/atomic_mb_set (and you're right that
> it's not obvious which side will include barriers, so you have to use
> the two together).
>
> >>> 2) The read side could legally be optimised out of the loop by
> >>> the compiler. (but in practice wont be because compilers won't
> >>> optimise that far).
> > That one's a trickier question. Compilers are absolutely capable
> > of optimizing that far, *but* the C rules about when it's allowed
> > to assume in-memory values remain unchanged are pretty
> > conservative. I think any function call in the loop will require
> > it to reload the value, for example. That said, a (compiler only)
> > memory barrier might be appropriate to ensure that reload.
>
> That's exactly what atomic_read provides.
So does that say I need the atomic_read but not the atomic_write -
which seems a bit weird, but I think only due to the naming.
Dave
>
> Paolo
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, David Gibson, 2015/03/13
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, Dr. David Alan Gilbert, 2015/03/13
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, David Gibson, 2015/03/16
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, Dr. David Alan Gilbert, 2015/03/18
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, David Gibson, 2015/03/19
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, Dr. David Alan Gilbert, 2015/03/19
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, David Gibson, 2015/03/22
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, Paolo Bonzini, 2015/03/30
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy,
Dr. David Alan Gilbert <=
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, Paolo Bonzini, 2015/03/30
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, Dr. David Alan Gilbert, 2015/03/31
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, Paolo Bonzini, 2015/03/30
- Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy, David Gibson, 2015/03/30