Markus Armbruster, le Tue 04 Mar 2008 15:32:57 +0100, a écrit :
> Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:
> > 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
Ok.
> It has no idea what I do with my VNC viewer window.
There is already a heuristic in that case, see the backoff: label in
vnc.c.
> >> 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?
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.
> >> 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.
Mmm, I'm afraid my english couldn't understand that sentence.
> > 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.
But the backend still needs to notify the frontend when it should switch
modes. Another way to go would be to only add to the PVFB protocol some
"expose on/off" events, and let the front-end decide of the rate to
adopt.
Samuel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home