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


[Xen-devel] vram_dirty vs. shadow paging dirty tracking

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] vram_dirty vs. shadow paging dirty tracking
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Tue, 13 Mar 2007 14:32:56 -0500
Delivery-date: Tue, 13 Mar 2007 12:32:07 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20070306)
When thinking about multithreading the device model, it occurred to me that it's a little odd that we're doing a memcmp to determine which portions of the VRAM has changed. Couldn't we just use dirty page tracking in the shadow paging code? That should significantly lower the overhead of this plus I believe the infrastructure is already mostly there in the shadow2 code.

Is this a sane idea?


Anthony Liguori

Xen-devel mailing list