This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Gianluca Guida <glguida@xxxxxxxxx>
Subject: Re: [Xen-devel] Shadow Page Tables in Xen
From: priya sehgal <priyagps@xxxxxxxxxxx>
Date: Wed, 22 Apr 2009 18:32:36 +0530 (IST)
Cc: gianluca.guida@xxxxxxxxxxxxx, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Wed, 22 Apr 2009 06:03:36 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1240405356; bh=o3nqmwBJUK9zVC+e+7zv5YnggrCtOdTNgGRjVHibI7E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=gXr1wi9BnF+SzwZhrh1zXAX9gvfkNbMxFxAFqNePcCFIhFieiZrrG5cOEMYDI7bEsCGiZ6e0554Xtk/8rVIcWM755l4XVpqfTlMPJ19us61G6omOd1dsDd3E9V6R5Q03zjZhp239QEcrGWeYqPN/AZyapCiEM97WkYzVkN4Tmik=
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=5MdzdrEy0B7FVVbFrY3aJGA8oDlF7tDxRai21iIJUJ8nEMPNpAUVK96SQ7900FSicyBxXH8lDnlSy4oJws7bt+6HVrm+PeRuQozUhy30X9KITODsFKA/tWcBKXxvJwVttKhRSwk305dYf+m6Tojub24JW/Rtl4WSR9bCuGlMgSI=;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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,


Xen-devel mailing list