Re: kvm somehow exempt from frequency scaling?

[Michael Riepe <michael-0QoEqw4nQxo@public.gmane.org>]

Hi!

David Abrahams wrote:
[...]
>>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).

What about the load?

By the way, how is your DISPLAY variable set? It should be ":0", not
"localhost:0" or "hostname:0". Otherwise video output will slow down
(and you'll probably see a lot of network load on the lo device).

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

Simple Directmedia Layer (see www.libsdl.org).
It's a library that Qemu uses for video output.

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

Maybe the qemu process is waiting for something (like an expose event
from the X server - which will never happen as long as the window is
invisible). What does ps/top report?

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

Since it's related to screen output, it's likely to be a qemu/SDL
problem. The kvm module itself doesn't do any screen i/o.

Does qemu behave differently if you use -no-kvm?

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV