On 08/08/2017 21:14, Dr. David Alan Gilbert wrote:
>> There is no barrier there that I can see. I know that it probably work
>> on x86, but in others? I think that it *** HERE we need that
>> memory barrier that we don't have.
> Yes, I think that's smp_mb_release() - and you have to do an
>
On Tue, Aug 08, 2017 at 06:04:54PM +0200, Juan Quintela wrote:
> Peter Xu wrote:
> > On Wed, Jul 19, 2017 at 08:02:39PM +0100, Dr. David Alan Gilbert wrote:
> >> * Juan Quintela (quint...@redhat.com) wrote:
>
> >> > struct MultiFDSendParams {
> >> > +/* not changed */
> >> > uint8_t id;
* Juan Quintela (quint...@redhat.com) wrote:
> "Dr. David Alan Gilbert" wrote:
> > * Juan Quintela (quint...@redhat.com) wrote:
> >> "Dr. David Alan Gilbert" wrote:
> >> > * Juan Quintela (quint...@redhat.com) wrote:
>
> ...
>
> >> > My feeling, without having fully thought it through, is that
"Dr. David Alan Gilbert" wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
>> "Dr. David Alan Gilbert" wrote:
>> > * Juan Quintela (quint...@redhat.com) wrote:
...
>> > My feeling, without having fully thought it through, is that
>> > the locking around 'address' can be simplified; especial
* Juan Quintela (quint...@redhat.com) wrote:
> "Dr. David Alan Gilbert" wrote:
> > * Juan Quintela (quint...@redhat.com) wrote:
> >> The function still don't use multifd, but we have simplified
> >> ram_save_page, xbzrle and RDMA stuff is gone. We have added a new
> >> counter and a new flag for
Peter Xu wrote:
> On Wed, Jul 19, 2017 at 08:02:39PM +0100, Dr. David Alan Gilbert wrote:
>> * Juan Quintela (quint...@redhat.com) wrote:
>> > struct MultiFDSendParams {
>> > +/* not changed */
>> > uint8_t id;
>> > QemuThread thread;
>> > QIOChannel *c;
>> > QemuSemaphor
"Dr. David Alan Gilbert" wrote:
> * Peter Xu (pet...@redhat.com) wrote:
>> On Wed, Jul 19, 2017 at 08:02:39PM +0100, Dr. David Alan Gilbert wrote:
>> ... here can we just do this?
>>
>> retry:
>> // don't take any lock, only read each p->address
>> for (i = 0; i < multifd_send_state->coun
"Dr. David Alan Gilbert" wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
>> The function still don't use multifd, but we have simplified
>> ram_save_page, xbzrle and RDMA stuff is gone. We have added a new
>> counter and a new flag for this type of pages.
>>
>> Signed-off-by: Juan Quintela
* Peter Xu (pet...@redhat.com) wrote:
> On Wed, Jul 19, 2017 at 08:02:39PM +0100, Dr. David Alan Gilbert wrote:
> > * Juan Quintela (quint...@redhat.com) wrote:
> > > The function still don't use multifd, but we have simplified
> > > ram_save_page, xbzrle and RDMA stuff is gone. We have added a ne
On Wed, Jul 19, 2017 at 08:02:39PM +0100, Dr. David Alan Gilbert wrote:
> * Juan Quintela (quint...@redhat.com) wrote:
> > The function still don't use multifd, but we have simplified
> > ram_save_page, xbzrle and RDMA stuff is gone. We have added a new
> > counter and a new flag for this type of
* Juan Quintela (quint...@redhat.com) wrote:
> The function still don't use multifd, but we have simplified
> ram_save_page, xbzrle and RDMA stuff is gone. We have added a new
> counter and a new flag for this type of pages.
>
> Signed-off-by: Juan Quintela
> ---
> hmp.c | 2 ++
The function still don't use multifd, but we have simplified
ram_save_page, xbzrle and RDMA stuff is gone. We have added a new
counter and a new flag for this type of pages.
Signed-off-by: Juan Quintela
---
hmp.c | 2 ++
migration/migration.c | 1 +
migration/ram.c | 90
12 matches
Mail list logo