|
xen-devel
Re: [Xen-devel] [RFC] PVFB: Add refresh period to XenStore parameters?
Turning off refresh on minimized windows certainly sounds worth it to me. Let's not forget that even though it currently may save "only" 6% CPU, the current VGA emulation only has 4 MB of video RAM. This will need to increase in the future up to at least a factor of 8 if we want to be able to support all resolutions that modern monitors can handle. I know there are more efficient update code than a complete memcmp() in the works, and that will probably be needed before we can do 2560x1600x32 double-buffered in guests at any reasonable CPU usage, but with those in place, needless updates is probably going to be a good thing to avoid.
Moreover, since I've been working with Xen in a client environment I know that being able to set the refresh rate higher than 30 Hz would also be a very welcome thing. The current unaccelerated VESA is actually surprisingly fast, and I the 30 Hz refresh is probably the main cause of people perceiving the client graphics as slow.
Just my 2 cents.
On Mon, Mar 3, 2008 at 8:18 PM, Samuel Thibault < samuel.thibault@xxxxxxxxxxxxx> wrote:
Hello,
Markus Armbruster, le Mon 03 Mar 2008 19:03:46 +0100, a écrit :
> > Sometimes the backend of PVFB knows that it doesn't need permanent
> > refresh, when the window is minimized for instance (no refresh at all),
> > or the administration tools know that the window is thumnailed, and so a
> > slow refresh rate is fine. Also, some users may want to tune the
> > refresh rate according to the smoothness they would like, balanced with
> > the CPU time that requires.
>
> Can you quantify the CPU time savings?
Something like 6% CPU on my test machine (by just slowing down from 30ms
to 1000ms interval).
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
window is minimized or reduced, it could stop or increase that polling
interval. With SDL and vnc, it can, but when going through PVFB that
information is lost.
> Are you sure they're worth the extra complexity?
At least watching a simple integer in XenStore is not very complex.
Note that this may not be a requirement, just the backend telling the
frontend what he'd prefer to see. If it's difficult for the frontend to
change the rate, then it can just ignore it, and the user won't be so
happy, that's all.
> Are you sure the ability to control the rate is required? Why isn't
> it sufficient to be able to switch updates off?
Being able to choose the smoothness of the interface is really a good
user experience. To my feeling, the current 30ms default rate of qemu
(7% CPU) is not so smooth (people don't use 30Hz monitors, to they? ;).
I usually prefer spending e.g. 14% CPU to get a 10ms rate, but of course
I don't want that CPU time to be used when the viewer is off screen.
Other people won't feel that need and can save CPU% by slowing it down.
Also, in other cases, you just need to have a snapshot of the VMs, so a
1s rate (or even 10s) makes sense.
> Another option is to send a suitable message through the ring.
Yes, but then it's hard for management tools (e.g. a gui that manages
VMs) to tune it, while a xenstore value is pretty easy to tinker with.
> The pvops PVFB uses fb_defio. I think we can change the refresh
> period there by changing xenfb_defio.delay, but that doesn't exactly
> look like something the API wants us to do.
Then that frontend may just ignore the rate. It's much less of a
concern, since that frontend doesn't use an active polling loop, and
thus consumes no CPU if nothing happens in the guest.
Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home