On Apr 22, 2009, at 3:02 PM, priya sehgal wrote:
There are various problems I can see with this approach:
- As Tim suggested, this will make the bandwidth required
to do live
migration much bigger (you're talking about increasing the
of memory to be sent from 1 to 1000 pages). So you should
account that yes, making bigger logdirty chunks will
pagefaults, but will increase the required network
bandwidth, which is
a very important parameter for live migration.
I think there is one thing missing in what I explained.
If a page in a group is written for the first time, all its neighbors
are marked as RW. But, their dirty bit might be off. Now, we maintain
a dirty group bitmap, which just stores the page groups that are
During the end of an epoch, when we are about to ship the pages
to the destination machine, we first check the groups which are
dirty. Scan through *each* page's PTE corresponding to that group to
if it is DIRTY. Only if the page is DIRTY is it sent over the network.
So, we do not send unwanted pages , only the ones marked DIRTY in the
Ok that seems, but please note that at the moment shadows always set
the DIRTY bit (unless we're tracking a VRAM address), so you might
have to set the dirty bit clean when propagating the shadow, which is
a bit too intrusive perhaps. But yes, that would work.
Also, you mentioned that the main performance bottleneck is due to
blowing up of the shadow page tables. Why is this required? Can't
the page table entries that were migrated in the last epoch be
cleaned up only and reset. Could you please elaborate on this ?
Yes. We could do that, as Ian suggested. There was no effort in
making live migration's shadow code fast, so nobody ever did it. Might
be good to do it, if you're interested in this case, and will be much
cleaner than your suggested effort, and perhaps way more interesting.
This comment, found in shadow_clean_dirty_bitmap might explain you a
/* Need to revoke write access to the domain's pages again.
* In future, we'll have a less heavy-handed approach to this,
* but for now, we just unshadow everything except Xen. */
Xen-devel mailing list