[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC] PVFB: Add refresh period to XenStore parameters?
Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes: > Markus Armbruster, le Tue 04 Mar 2008 16:48:20 +0100, a Ãcrit : >> Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes: >> > Markus Armbruster, le Tue 04 Mar 2008 15:32:57 +0100, a Ãcrit : >> >> > In my case, I'm using PVFB to expose the stubdomain qemu display. The >> >> > problem is that every 30ms, qemu wakes up to memcmp() the whole video >> >> > memory with a shadow buffer so as to track changes. If it knew that the >> >> >> >> Wait a second! You're talking about *your* frontend here, aren't you? >> >> >> >> Maintaining a shadow copy in the frontend (which requires compare and >> >> copy) to minimize copying in the backend sounds pretty self-defeating >> >> to me. Why is this a good idea? >> > >> > Because in my case the domain is HVM, and I don't want to trap the >> > writes to the video RAM since that's awfully slow. >> > >> >> Why not refrain from sending update messages and have the backend >> >> simply redisplay everything? >> > >> > Because as explained above, I can't avoid a shadow copy. >> >> I imagine (perhaps naively): >> >> * The domU writes to a framebuffer provided by the frontend. >> >> * The framebuffer (not a copy of it) can be shared with the backend, >> which only reads. > > Well, that's not always the case, when the guest is in text mode for > instance, the PV shared buffer is converted from the guest text buffer. Optimize for the common case. Which I figure is a 32 bpp framebuffer. Anyway, compare and copy for some legacy 80x25 text mode shouldn't eat that much CPU. >> * If the frontend can track changes efficiently, it sends update >> messages to the backend, which can use them to only redisplay >> changed areas. >> >> Else the backend needs to assume the worst and periodically >> redisplay everything. It is free to maintain a shadow copy to track >> changes and minimize redisplay, if that turns out to be faster. >> >> What's wrong with that? > > Well, that was actually my next target :) > (but for that we badly need the resize/redepth support). We'll see another iteration of the patch soon, I hope. > However, that doesn't solve something that still bugs me, which is > that the VGA emulation layer wakes up every 30ms to just notice that > the width/height/depth registers didn't change etc. even if the actual > window is not shown. > > Samuel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |