Re: [Xen-devel] Shadow Page Tables in Xen

[priya sehgal <priyagps@xxxxxxxxxxx>]

Hi Gianluca,

> 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
> granularity
> of memory to be sent from 1 to 1000 pages). So you should
> take into
> account that yes, making bigger logdirty chunks will
> decrease the
> 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 dirty.
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 determine
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
RW-enabled groups.


I hope this time it is much clearer. Please let me know your comments
on the same.

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 ?

Thanks and Regards,
Priya.



      

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel