[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH 3/3] Add shadow VRAM



Keir-

Nice try but I thought of that :-)  The code checks at run time also,
for just the reason you state.  Also, I did measure and the runtime
check adds no measurable overhead.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Donald.D.Dugger@xxxxxxxxx
Ph: (303)440-1368 

>-----Original Message-----
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx] 
>Sent: Wednesday, March 15, 2006 4:07 PM
>To: Dugger, Donald D
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] [PATCH 3/3] Add shadow VRAM
>
>
>On 15 Mar 2006, at 21:57, Donald D. Dugger wrote:
>
>> Add a shadow VRAM to track changes to the real VRAM.  When the guest
>> OS was given write access to the VRAM the device model tracked all
>> VRAM changes by updating the entire screen on every output loop,
>> causing significant overhead (a CPU bound loop in a guest slows down
>> by about 35%) and significant mouse latency (VNC uses the same data
>> path for mouse events and video updates).  With the shadow VRAM only
>> modified pages need to be updated and the comparison of the shadow
>> VRAM to the real VRAM only adds ~4% overhead while eliminating the
>> mouse latencies.
>
>Checking for SSE2 support on the build machine isn't good 
>enough, since 
>we may install on a totally different machine (distro binary packages, 
>for example). Can you make it a run-time decision? Shouldn't add 
>significant overhead?
>
>  -- Keir
>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.