WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [PATCH]RFC: VGA accleration using shadow PTE D-bit to co

To: "Tim Deegan" <Tim.Deegan@xxxxxxxxxxxxx>, "Huang, Xinmei" <xinmei.huang@xxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH]RFC: VGA accleration using shadow PTE D-bit to construct LFB dirty bitmap
From: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>
Date: Mon, 30 Jul 2007 13:11:16 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Ian.Pratt@xxxxxxxxxxxx
Delivery-date: Mon, 30 Jul 2007 05:09:34 -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>
References: <20070730085807.GB24708@xxxxxxxxxxxxxxxxxxxxx> <823A93EED437D048963A3697DB0E35DE8D0FC0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20070730110037.GD24708@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcfSmPsmUkkzcSUoTieZ2E28u26g3AAB9ogg
Thread-topic: [Xen-devel] [PATCH]RFC: VGA accleration using shadow PTE D-bit to construct LFB dirty bitmap
> If there is one kernel-mode mapping of the LFB, though, I'd 
> expect it to be fairly rarely torn down; it would need the 
> shadows of all processes that were ever running when the 
> kernel touched the video RAM to be reaped.  So just marking 
> the page dirty when you make or tear down a vram mapping 
> should be better.

Ideally, we'd return 'all-dirty' for a missing shadow page just once,
and then 'all-clean' on subsequent scans until the PT page gets
reshadowed. 

I can imagine that if an OS'es screen blanker kicked in we might not see
any further writes to the LFB, and this could lead to the shadows
ultimately getting evicted, resulting in pessimal performance if we're
always returning 'all-dirty'.

There's no real need to do this on a page granularity -- if any of our
LFB-mapping shadow pages have been evicted we could evict them all. I'm
not sure this makes things any easier, though.

We can use missing shadows as an optimization: if we return a bit map
with 'everything clean' a few times in a row, we are probably better off
pro-actively unshadowing the page to avoid even doing the dirty bit
scanning.

Best,
Ian

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