Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:
> Hello,
>
> Markus Armbruster, le Mon 03 Mar 2008 19:03:46 +0100, a écrit :
>> Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home