qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [v8 08/14] migration: Add the core code of multi-thread


From: Dr. David Alan Gilbert
Subject: Re: [Qemu-devel] [v8 08/14] migration: Add the core code of multi-thread compression
Date: Thu, 7 May 2015 15:13:59 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

* Paolo Bonzini (address@hidden) wrote:
> 
> 
> On 15/04/2015 11:26, Liang Li wrote:
> > +    if (ret != RAM_SAVE_CONTROL_NOT_SUPP) {
> > +        if (ret != RAM_SAVE_CONTROL_DELAYED) {
> > +            if (bytes_xmit > 0) {
> > +                acct_info.norm_pages++;
> 
> I don't think you can mix non-atomic and atomic increments like
> this---or if you can, you really should document why.
> 
> Perhaps you can add a counter to the CompressParam struct, and sum all
> counters in norm_mig_pages_transferred/norm_mig_bytes_transferred (the
> latter probably should just call norm_mig_pages_transferred)?

The 'ram_save_compressed_page' that Liang Li has added here is basically
the same as the ram_save_page we've already got but with the extra
bits for compression, and this non-atomic inc is in the code simply copied
to handle the 'ram_control_save_page' case (i.e. RDMA).

So it is safe, because I don't think any pages will get handed to the 
compression threads (and hence hit the atomic inc's) if RDMA is hooking
the ram_control_save_page.

It's a good question what will happen with RDAM+compression enabled;
if we're lucky it'll just do uncompressed-RDMA.

Dave

> 
> Paolo
> 
> > +            } else if (bytes_xmit == 0) {
> > +                acct_info.dup_pages++;
> > +            }
> > +        }
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK



reply via email to

[Prev in Thread] Current Thread [Next in Thread]