Re: kvm somehow exempt from frequency scaling?

David Abrahams
2007-04-11T18:31:39Z

on Wed Apr 11 2007, Michael Riepe <michael-AT-mr511.de> wrote:

> 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?

It seems to make progress. I can play internet radio in the VM and I
keep hearing it (glitchy, but it doesn't stop).

>> 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.

SDL?

> 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".

Yeah, but I don't care about the window being updated. I want the
virtual CPU to make progress. Switching workspaces is literally like
suspending the VM!

> 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).

I don't either, but it's not 100% clear to me yet that this is a qemu
problem. Maybe I'll report it in a QEMU forum as well.

--
Dave Abrahams
Boost Consulting