Re: [RFC] PVFB: Add refresh period to XenStore parameters?

[Samuel Thibault <samuel.thibault@eu.citrix.com>]

Hello,

Markus Armbruster, le Mon 03 Mar 2008 19:03:46 +0100, a écrit :
> Samuel Thibault <samuel.thibault@eu.citrix.com> writes:
> > 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