RE: [Xen-devel] [PATCH]RFC: VGA accleration using shadow PTE D-bit to construct LFB dirty bitmap

["Huang, Xinmei" <xinmei.huang@xxxxxxxxx>]

>-----Original Message-----
>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxx] 
>Sent: 2007年7月30日 20:11
>To: Tim Deegan; Huang, Xinmei
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Ian.Pratt@xxxxxxxxxxxx
>Subject: RE: [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. 

Agreed. Re-drawing is much time-consuming. We'd avoid unnecessary re-drawing if 
possible.

>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.

Unshadowing & re-shadowing the all LFB pages are expensive. 
Performance would vary because the characteristic of graphic-intensive workload 
and the value of N -- the times of continuous 'all-clean'.
I'm not sure this brings suffient benefit.

>
>Best,
>Ian
>
-Xinmei

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