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

[Markus Armbruster <armbru@redhat.com>]

Samuel Thibault <samuel.thibault@eu.citrix.com> writes:

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

I'm not sure I understand how this is supposed to work.  Commonly, my
display is somewhere else, and all the backend knows of it is a VNC
connection.  It has no idea what I do with my VNC viewer window.  Can
you explain?

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

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?

Why not refrain from sending update messages and have the backend
simply redisplay everything?  tools/ioemu/hw/xenfb.c doesn't implement
that mode, but it shouldn't be hard.  And then you could control the
refresh rate solely in the backend, without having to communicate with
the frontend.

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

I'm concerned that we're papering over performance problems instead of
solving them.

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

Depends on who does the tinkering.  If its the backend, then nothing
is easier than sending a message through the ring.

On the other hand, if this is just a hack to make a particular
frontend less inefficient, then using XenStore at least keeps it out
of the PVFB protocol.

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