Re: kvm somehow exempt from frequency scaling?

Michael Riepe
2007-04-11T17:39:11Z

Hi!

David Abrahams wrote:
[...]
>>More data: it definitely seems to make a difference whether the VM's
>>desktop is showing. If I switch Gnome workspaces so it's not visible,
>>it doesn't seem to drive the frequency up.

Because it doesn't have to redraw the window?

What happens if you hide the qemu window below another one, e.g. your
favorite web browser?

> In fact, kvm doesn't seem to make any progress at all :(. I'm
> currently going through the "microsoft update" dance on a VM there,
> and I literally left for an hour during which there was no progress
> because the QEMU window wasn't visible.
>
> Even stranger, if I minimize the QEMU window and then switch
> workspaces, it gets plenty of cycles.

I guess that's a qemu and/or SDL issue.

Ideally, the screen should only be updated when the window is mapped
(via XMapWindow) *and* visible (that is, neither fully obscured nor
moved outside the visible part of the screen). Since "fully obscured" is
hard to test for, this usually translates to "mapped and not off-screen".

When a window is minimized ("iconified"), it usually is unmapped and
another one (the "icon window") is mapped instead. When switching
workspaces, however, some window managers just move the window away (say
to x=10000,y=10000) but keep it mapped. If there is no test for
visibility (or if the test doesn't work correctly), SDL may happily
continue updating the window's contents - and that will burn a lot of
cycles.

IMO, there's a lot of room for improvement here. But it has nothing to
do with kvm in the first place (unless you consider qemu an integral
part of kvm, which I don't).

--
Michael "Tired" Riepe <michael-0QoEqw4nQxo@public.gmane.org>
X-Tired: Each morning I get up I die a little