qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 0/6] migration: differentiate between pages and


From: Li, Liang Z
Subject: Re: [Qemu-devel] [PATCH 0/6] migration: differentiate between pages and bytes
Date: Thu, 26 Feb 2015 05:15:50 +0000


> -----Original Message-----
> From: Dr. David Alan Gilbert [mailto:address@hidden
> Sent: Tuesday, February 17, 2015 10:24 PM
> To: Juan Quintela
> Cc: address@hidden; Li, Liang Z
> Subject: Re: [Qemu-devel] [PATCH 0/6] migration: differentiate between
> pages and bytes
> 
> * Juan Quintela (address@hidden) wrote:
> > Hi
> >
> > (Li special edition)
> >
> > Current migration code returns number of bytes transferred and from
> > there we decide if we.have sent something or not.  Problem, we need
> > two results: number of pages written, and number of bytes written
> > (depending on compression, zero pages, etc, it is not possible to
> > derive one value from the other).
> >
> > So, I changed all relevant function to return the number of written
> > pages, and then pass as uint64_t *bytes_transferred to update the
> > written bytes.
> >
> > On current code, makes things a bit easier to understand, but is not
> > strictely necesary.  But for the compression patches from Li, it makes
> > a big difference, we can return that we have written a page, even if
> > we have just started the write, but having writtten in reality zero
> > bytes.
> >
> > Once there, I add doxygen documentation to all function that I touched
> > (yes, I was long due).
> >
> > save_block_hdr really saved headers for pages, not blocks.  Rename it,
> > and simplify the interface.
> >
> > Li, does this make your life easier?  I hope so.  Should make really
> > easy to remove the one_bytes_sent "hack", and allow my other
> suggestions.
> >
> > Comments?
> 
> I like it; it generally seems to make sense to separate the concept of whether
> we've actually sent any pages from the actual byte counting.
> 
> While you're there though; do we actually care about bean counting the
> individual header bytes?  For example the &bytes_transferred += 1 in the
> RAM_SAVE_FLAG_COMPRESS case where it puts the 0, or the EOS mark
> where
> we add 8 bytes?   Do we need to keep track of anything other than
> stuff that's potentially big enough to make an impact on the bandwidth
> calculations?
> 

Can pos of QEMUFile be used to counting the transferred bytes ?

Liang



reply via email to

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