WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] PVFB: Add refresh period to XenStore parameters?
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Tue, 04 Mar 2008 15:32:57 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 04 Mar 2008 06:33:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080303191804.GA11699@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> (Samuel Thibault's message of "Mon\, 3 Mar 2008 19\:18\:04 +0000")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20080229120806.GA8268@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <873ar7ptvh.fsf@xxxxxxxxxxxxxxxxx> <20080303191804.GA11699@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
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