on Wed Apr 11 2007, Michael Riepe <michael-AT-mr511.de> wrote:
> 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?
kvm's load is independent of whether the window is obscured or
minimized, but when it's not on the visible Gnome workspace, the load
drops to near zero (and kvm gets nothing, or not much, done).
> 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).
It's ":0.0"
>>>>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.
Hm.
>>>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?
I've been using top to observe the load. The state as reported by "ps
waux" is either Rl+ or Sl+. Most of the time when qemu is on the
visible workspace, it's Rl+. When not on the visible workspace, the
%CPU goes way down and the state is usually "Sl+". Unless, of course,
the window is minimized, in which case it gets plenty of time to run.
>>>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.
That doesn't explain why the "invisible workspace effect" doesn't
apply to iconified windows.
>>>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?
Haven't tried that one yet.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Don't Miss BoostCon 2007! ==> http://www.boostcon.com
-------------------------------------------------------------------------
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
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
