Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx> writes:
> 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.
I imagine (perhaps naively):
* The domU writes to a framebuffer provided by the frontend.
* The framebuffer (not a copy of it) can be shared with the backend,
which only reads.
* If the frontend can track changes efficiently, it sends update
messages to the backend, which can use them to only redisplay
changed areas.
Else the backend needs to assume the worst and periodically
redisplay everything. It is free to maintain a shadow copy to track
changes and minimize redisplay, if that turns out to be faster.
What's wrong with that?
>> >> 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.
Sorry about that, let me try again. I'm concerned that we're working
around serious performance problems instead of solving them properly.
[...]
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home