[Qemu-devel] qemu-system-ppc seems slow today.

[Qemu-devel] qemu-system-ppc seems slow today.

[Lennart Sorensen]

I just did an svn checkout since some of the changes in the last 5 days
since my last build sounded useful.

Well something not so good also happened.  With the build from 5 days
ago, qemu would happily use 100% of one cpu core, and run at a decent
speed.  Today's build seems to only want to use 10 to 20% of a cpu core
and runs very slowly.

Is this a known problem, or does this need some investigating?  Is there
any kind of bisect like facility in svn to help track it down?  Anyone
want to take a stab and guessing which commit did this?

-- 
Len Sorensen

Re: [Qemu-devel] qemu-system-ppc seems slow today.

[Aurelien Jarno]

On Mon, Jan 19, 2009 at 11:26:33AM -0500, Lennart Sorensen wrote:
> I just did an svn checkout since some of the changes in the last 5 days
> since my last build sounded useful.
> 
> Well something not so good also happened.  With the build from 5 days
> ago, qemu would happily use 100% of one cpu core, and run at a decent
> speed.  Today's build seems to only want to use 10 to 20% of a cpu core
> and runs very slowly.

Why do you mean by very slow? How do you measure that? On my side the
boot time is the same within a couple of second between last "5 days
ago" and now.

> Is this a known problem, or does this need some investigating?  Is there
> any kind of bisect like facility in svn to help track it down?  Anyone
> want to take a stab and guessing which commit did this?
> 

The fist thing would be to get the exact revision from "5 days ago". And
then you can try to bisect using git. There is a git mirror of the
current SVN on git.kernel.org

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] qemu-system-ppc seems slow today.

[Lennart Sorensen]

On Mon, Jan 19, 2009 at 06:09:12PM +0100, Aurelien Jarno wrote:
> Why do you mean by very slow? How do you measure that? On my side the
> boot time is the same within a couple of second between last "5 days
> ago" and now.

Boot time of about a minute versus about 6 or 7 minutes.  Seems to scale
completely with the drop in cpu usage.  Use 1/6 of the cpu and run 6
times slower.

> The fist thing would be to get the exact revision from "5 days ago". And
> then you can try to bisect using git. There is a git mirror of the
> current SVN on git.kernel.org

OK, I am trying to find how I can get the svn commit number from the
result of make -k tar.  All I have found so far just says svn.

I of course didn't keep the previous checkout since I just did svn
update in the same directory.

Well there can't be that many commits in 5 days, so I should be able to
pick somewhere to start a bisect from.

-- 
Len Sorensen

Re: [Qemu-devel] qemu-system-ppc seems slow today.

[Lennart Sorensen]

On Mon, Jan 19, 2009 at 12:49:14PM -0500, Lennart Sorensen wrote:
> Boot time of about a minute versus about 6 or 7 minutes.  Seems to scale
> completely with the drop in cpu usage.  Use 1/6 of the cpu and run 6
> times slower.
> 
> OK, I am trying to find how I can get the svn commit number from the
> result of make -k tar.  All I have found so far just says svn.
> 
> I of course didn't keep the previous checkout since I just did svn
> update in the same directory.
> 
> Well there can't be that many commits in 5 days, so I should be able to
> pick somewhere to start a bisect from.

Hmm, so if I run 'watch -n 1 date' in qemu and on the host, in the time
10 seconds pass in qemu, 25 seconds passed on the host.  qemu thinks it
is running as fast as before, but its concept of real time is wrong.

With the build I did on january 14th, the qemu and the host are in sync
timewise and qemu is way more responsive (at the cost of a lot of cpu of
course).

-- 
Len Sorensen

Re: [Qemu-devel] qemu-system-ppc seems slow today.

[Aurelien Jarno]

On Mon, Jan 19, 2009 at 01:07:14PM -0500, Lennart Sorensen wrote:
> On Mon, Jan 19, 2009 at 12:49:14PM -0500, Lennart Sorensen wrote:
> > Boot time of about a minute versus about 6 or 7 minutes.  Seems to scale
> > completely with the drop in cpu usage.  Use 1/6 of the cpu and run 6
> > times slower.
> > 
> > OK, I am trying to find how I can get the svn commit number from the
> > result of make -k tar.  All I have found so far just says svn.
> > 
> > I of course didn't keep the previous checkout since I just did svn
> > update in the same directory.
> > 
> > Well there can't be that many commits in 5 days, so I should be able to
> > pick somewhere to start a bisect from.
> 
> Hmm, so if I run 'watch -n 1 date' in qemu and on the host, in the time
> 10 seconds pass in qemu, 25 seconds passed on the host.  qemu thinks it
> is running as fast as before, but its concept of real time is wrong.
> 
> With the build I did on january 14th, the qemu and the host are in sync
> timewise and qemu is way more responsive (at the cost of a lot of cpu of
> course).

That works perfectly here.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] qemu-system-ppc seems slow today.

[Lennart Sorensen]

On Mon, Jan 19, 2009 at 07:39:02PM +0100, Aurelien Jarno wrote:
> That works perfectly here.

So far I have tested 4 checkouts.

0.9.1git-5653494a49db20ca6b22b32fa07a73b9e2f26169 slow          Sat Jan 17 20:47:10 2009 +0000
0.9.1git-63c75dcd669d011f438421980b4379827da4bb1c slow          Fri Jan 16 22:32:33 2009 +0000
0.9.1git-6517ca2a760227b7eb1ded729b0e26f0fa61d73c segfault      Fri Jan 16 07:31:51 2009 +0000
0.9.1git-75f765317b0bce0ad250f665c24c844d775ea4da normal        Wed Jan 14 21:42:48 2009 +0000
0.9.1git-1eff7fbf116790aaacc8f89def68be11149626cc normal        Tue Jan 13 23:12:34 2009 +0000 (no quik boot though)

So so far I know something changed between
75f765317b0bce0ad250f665c24c844d775ea4da and
63c75dcd669d011f438421980b4379827da4bb1c

All I am doing is running qemu-system-ppc -hda debian-lenny.img (which
has debian lenny installed with the standard debian 2.6.26 kernel).

I will do more builds until I find when it "broke".

-- 
Len Sorensen

Re: [Qemu-devel] qemu-system-ppc seems slow today.

[Lennart Sorensen]

On Mon, Jan 19, 2009 at 02:42:21PM -0500, Lennart Sorensen wrote:
> On Mon, Jan 19, 2009 at 07:39:02PM +0100, Aurelien Jarno wrote:
> > That works perfectly here.
> 
> So far I have tested 4 checkouts.
> 
> 0.9.1git-5653494a49db20ca6b22b32fa07a73b9e2f26169 slow          Sat Jan 17 20:47:10 2009 +0000
> 0.9.1git-63c75dcd669d011f438421980b4379827da4bb1c slow          Fri Jan 16 22:32:33 2009 +0000
> 0.9.1git-6517ca2a760227b7eb1ded729b0e26f0fa61d73c segfault      Fri Jan 16 07:31:51 2009 +0000
> 0.9.1git-75f765317b0bce0ad250f665c24c844d775ea4da normal        Wed Jan 14 21:42:48 2009 +0000
> 0.9.1git-1eff7fbf116790aaacc8f89def68be11149626cc normal        Tue Jan 13 23:12:34 2009 +0000 (no quik boot though)
> 
> So so far I know something changed between
> 75f765317b0bce0ad250f665c24c844d775ea4da and
> 63c75dcd669d011f438421980b4379827da4bb1c
> 
> All I am doing is running qemu-system-ppc -hda debian-lenny.img (which
> has debian lenny installed with the standard debian 2.6.26 kernel).
> 
> I will do more builds until I find when it "broke".

So after many builds, and eventually selectively applying some patches
to fix segfaults and build failures, I tracked the problem down to
commit 7d957bd8cbcbf56f7916d375e65042d767f544b5 in git (commit 6336 in
svn).  I wish there weren't so many checkins that failed to build or
segfaulted at start.  Oh well.  Too many targets to test I guess.

Now I have been using qemu for a while by doing:

'ssh -X fastserver' and running qemu there.  With the new display code
this has made qemu very slow and hardly useable.

Now if I use vnc to connect to qemu, the performance is great.  I
suppose I could use that, but I am still wondering why the new display
code made the X11 over ssh so awful.  Any ideas?

Oh and vnc doesn't work with xvnc4client, giving an error about rect too
big:
 CConn:       connected to host rceng02 port 5901
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 6 (8bpp) rgb222
 CConn:       Using ZRLE encoding
 CConn:       Throughput 20000 kbit/s - changing to hextile
 encoding
 CConn:       Throughput 20000 kbit/s - changing to full colour
 CConn:       Using pixel format depth 24 (32bpp) little-endian
 rgb888
 CConn:       Using hextile encoding
Rect too big: 5x1536 at 600,0 exceeds 800x600
 main:        Rect too big

vinagre on the other hand seems OK.  Odd.

-- 
Len Sorensen

Re: [Qemu-devel] qemu-system-ppc seems slow today.

[François Revol]

> Oh and vnc doesn't work with xvnc4client, giving an error about rect
> too
> big:

It might be due to a resolution change, reconnecting should fix it.
At least the xvnc4viewer works fine here with svn HEAD, appart some
spurious errors like these, but I didn't have any recently.

François.

[Qemu-devel] Extremely slow graphic updates (was: qemu-system-ppc seems slow today)

[Paul Brook]

> 'ssh -X fastserver' and running qemu there.  With the new display code
> this has made qemu very slow and hardly useable.

I'm seeing similar extreme slowness even on a local machine.

Particularly noticeable is that the monitor displayed on a qemu virtual SDL 
console (i.e. the defaut) slow enough to be practically unusable. It's taking 
the best part of a second to rendering a character.

This is on an otherwise fast machine that does not have accelerated X drivers, 
which suggests we're doing something really dumb like reading from video ram.

I have confirmed that this is caused by r6336.

Paul

[Qemu-devel] Re: Extremely slow graphic updates

[Anthony Liguori]

Paul Brook wrote:
>> 'ssh -X fastserver' and running qemu there.  With the new display code
>> this has made qemu very slow and hardly useable.
>>     
>
> I'm seeing similar extreme slowness even on a local machine.
>
> Particularly noticeable is that the monitor displayed on a qemu virtual SDL 
> console (i.e. the defaut) slow enough to be practically unusable. It's taking 
> the best part of a second to rendering a character.
>
> This is on an otherwise fast machine that does not have accelerated X drivers, 
> which suggests we're doing something really dumb like reading from video ram.
>
> I have confirmed that this is caused by r6336.
>   

I'll look into this tomorrow morning.

Regards,

Anthony Liguori

> Paul
>   

[Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

Paul Brook wrote:

>> 'ssh -X fastserver' and running qemu there.  With the new display code
>> this has made qemu very slow and hardly useable.
> 
> I'm seeing similar extreme slowness even on a local machine.
> 
> Particularly noticeable is that the monitor displayed on a qemu virtual SDL 
> console (i.e. the defaut) slow enough to be practically unusable. It's taking 
> the best part of a second to rendering a character.
> 
> This is on an otherwise fast machine that does not have accelerated X drivers, 
> which suggests we're doing something really dumb like reading from video ram.

We are not doing anything that dumb (anything that I am aware of :)

> I have confirmed that this is caused by r6336.
> 

What is the quickest way for me to reproduce this problem?
Have you seen this on ppc emulation only?

I gather that the guest is in text mode. Have you seen this in graphical
mode too? If yes, what was the resolution of the guest?

What is the resolution of your host? What X11 extensions are you using?
Do you set SDL_VIDEODRIVER anywhere?

Sorry for the list of questions, I am just trying to better understand
the issue.

[Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

Stefano Stabellini wrote:

> Paul Brook wrote:
> 
>>> 'ssh -X fastserver' and running qemu there.  With the new display code
>>> this has made qemu very slow and hardly useable.
>> I'm seeing similar extreme slowness even on a local machine.
>>
>> Particularly noticeable is that the monitor displayed on a qemu virtual SDL 
>> console (i.e. the defaut) slow enough to be practically unusable. It's taking 
>> the best part of a second to rendering a character.
>>
>> This is on an otherwise fast machine that does not have accelerated X drivers, 
>> which suggests we're doing something really dumb like reading from video ram.
> 
> We are not doing anything that dumb (anything that I am aware of :)
> 
>> I have confirmed that this is caused by r6336.
>>
> 
> What is the quickest way for me to reproduce this problem?
> Have you seen this on ppc emulation only?
> 
> I gather that the guest is in text mode. Have you seen this in graphical
> mode too? If yes, what was the resolution of the guest?
> 
> What is the resolution of your host? What X11 extensions are you using?
> Do you set SDL_VIDEODRIVER anywhere?
> 
> Sorry for the list of questions, I am just trying to better understand
> the issue.
> 
> 


And most important: are you sure it is an SDL only problem?

[Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 11:28:28AM +0000, Stefano Stabellini wrote:
> And most important: are you sure it is an SDL only problem?

It does not affect VNC.  I haven't managed to test text mode yet since
that requires figuring out how to make quik boot pass in a serial
console parameter.  I haven't figured that out yet.

-- 
Len Sorensen

[Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 11:22:30AM +0000, Stefano Stabellini wrote:
> We are not doing anything that dumb (anything that I am aware of :)

Could it be that it is trying to use shared video ram even in cases
where that is a very bad idea?

> What is the quickest way for me to reproduce this problem?
> Have you seen this on ppc emulation only?

Boot qemu-system-ppc with default options.  I use debian lenny (2.6.26
kernel).  I think it runs 800x600 resolution by default.  

> I gather that the guest is in text mode. Have you seen this in graphical
> mode too? If yes, what was the resolution of the guest?

I have only run in graphics mode.  I don't have my image setup for text
mode.  However VNC mode is NOT slow.  Of course VNC would not be using
shared memory remotely.

> What is the resolution of your host? What X11 extensions are you using?
> Do you set SDL_VIDEODRIVER anywhere?

Nope.  My xorg.conf doesn't list any extensions, so whatever the
defaults are.  I can check.

> Sorry for the list of questions, I am just trying to better understand
> the issue.

Worth asking.

-- 
Len Sorensen

[Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

Lennart Sorensen wrote:

> On Tue, Jan 20, 2009 at 11:22:30AM +0000, Stefano Stabellini wrote:
>> We are not doing anything that dumb (anything that I am aware of :)
> 
> Could it be that it is trying to use shared video ram even in cases
> where that is a very bad idea?


There are no such cases I am aware of.

 
>> What is the quickest way for me to reproduce this problem?
>> Have you seen this on ppc emulation only?
> 
> Boot qemu-system-ppc with default options.  I use debian lenny (2.6.26
> kernel).  I think it runs 800x600 resolution by default.  


Are you using Xorg in the guest? What is the guest color depth?

 
>> What is the resolution of your host? What X11 extensions are you using?
>> Do you set SDL_VIDEODRIVER anywhere?
> 
> Nope.  My xorg.conf doesn't list any extensions, so whatever the
> defaults are.  I can check.
> 

I assume your host is an i386 machine.
What is the color depth of your Xorg server running on the host?

[Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 03:21:59PM +0000, Stefano Stabellini wrote:
> There are no such cases I am aware of.

Hopefully not.  So far I looked at 'is_buffer_shared' and so far it
always returns 0, so at least that seems to indicate it isn't using
shared memory (I believe).

> Are you using Xorg in the guest? What is the guest color depth?

No.  Just text console.  Of course the text console is a framebuffer
being that it is emulating a powermac g3.  I don't pass any arguments to
qemu-system-ppc other than -hda and a disk image.  So whatever the
default is.
 
> I assume your host is an i386 machine.
> What is the color depth of your Xorg server running on the host?

Well I run 24bit on my machine, and then use ssh -X to reach the machine
I run qemu on, so it would be 24bit (probably 32bit really).  The
machine running qemu is running i386 (although the kernel is amd64, not
that it matters).

Here is a diff of dmesg from the vnc boot to the default X mode (slow):

# diff -u /tmp/dmesg.normal.vnc.log /tmp/dmesg.slow.log
--- /tmp/dmesg.normal.vnc.log   2009-01-20 10:46:56.000000000 -0500
+++ /tmp/dmesg.slow.log 2009-01-20 10:45:17.000000000 -0500
@@ -39,17 +39,17 @@
 GMT Delta read from XPRAM: 0 minutes, DST: off
 WARNING: Estimating decrementer frequency (not found)
 WARNING: Estimating processor frequency (not found)
-time_init: decrementer frequency = 16.604350 MHz
+time_init: decrementer frequency = 38.257166 MHz
 time_init: processor frequency   = 1000.000000 MHz
-clocksource: timebase mult[f0e6962] shift[22] registered
-clockevent: decrementer mult[440] shift[16] cpu[0]
+clocksource: timebase mult[688e3a3] shift[22] registered
+clockevent: decrementer mult[9cb] shift[16] cpu[0]
 Console: colour dummy device 80x25
 console handover: boot [udbg0] -> real [tty0]
 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
 Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
 High memory: 0k
 Memory: 138692k/147456k available (3760k kernel code, 8600k reserved, 152k data, 347k bss, 220k init)
-Calibrating delay loop... 33.15 BogoMIPS (lpj=66304)
+Calibrating delay loop... 76.28 BogoMIPS (lpj=152576)
 Security Framework initialized
 SELinux:  Disabled at boot.
 Capability LSM initialized
@@ -76,7 +76,7 @@
 Freeing initrd memory: 2383k freed
 Thermal assist unit using timers, shrink_timer: 500 jiffies
 audit: initializing netlink socket (disabled)
-type=2000 audit(1232466137.128:1): initialized
+type=2000 audit(1232465912.752:1): initialized
 VFS: Disk quotas dquot_6.5.1
 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
 msgmni has been set to 275
@@ -111,7 +111,7 @@
 TCP cubic registered
 NET: Registered protocol family 17
 registered taskstats version 1
-platform ppc-rtc.0: setting system clock to 2009-01-20 15:42:17 UTC (1232466137)
+platform ppc-rtc.0: setting system clock to 2009-01-20 15:38:35 UTC (1232465915)
 Freeing unused kernel memory: 220k init
 ADB mouse at 3, handler set to 2
 input: ADB mouse as /class/input/input2

The decrementer frequency is very difference, as are the bogomips and the timebase.

I was trying to come up with a simple test case to show the problem,
but found another one.  If I simply run qemu-system-ppc -vnc :1 I get
nothing on VNC.  Using -sdl I get the openbios prompt.  If I use both
-vnc :1 and -sdl I get openbios showing on both.  vnc by itself seems to
only start displaying something once something other than openbios is
running, like the bootloader or linux kernel.  That doesn't seem right.

Test case:

Get the debian lenny (testing) business card iso from (60MB)
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/powerpc/iso-cd/debian-testing-powerpc-businesscard.iso

qemu-system-ppc -cdrom debian-testing-powerpc-businesscard.iso

at openbios prompt type 'boot cdrom:'

hit enter to accept default choices at yaboot prompt and debian location
prompts.  Stop when it gets to asking which mirror to use.  Switch to
the second VT using alt+F2.

run 'sleep 5'.  Time how long it really takes.  Mine takes about 13 or
14 seconds.

Previous to 6336 it took 5 seconds.  When using VNC, it takes 5 seconds,
although since you don't see the openbios prompt in vnc mode, it's
tricky to do this.  I did my test after doing an install so that it
boots.

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Samuel Thibault]

Lennart Sorensen, le Tue 20 Jan 2009 11:55:35 -0500, a écrit :
> use ssh -X to reach the machine I run qemu on,

Ah, that rings me a bell. There was problem with that, something like
now that sdl uses SDL_BlitSurface/SDL_Flip there is an X roundtrip,
which is awfully slow over ssh.  Would you be able to try without ssh?

Samuel

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 06:09:33PM +0100, Samuel Thibault wrote:
> Ah, that rings me a bell. There was problem with that, something like
> now that sdl uses SDL_BlitSurface/SDL_Flip there is an X roundtrip,
> which is awfully slow over ssh.  Would you be able to try without ssh?

That would be tricky since it is running on another machine.  I will
try.  I do believe someone else said that they could confirm the slow
behaviour with 6336 running locally as well.  It may be that some X
drivers are slow at SDL_Flip and SDL_BlitSurface.

Hmm, my X server isn't compiled to allow tcp connections (only local
sockets), so avoiding ssh looks hard too.

Maybe Xvnc can do it.  yeah Xvnc4 as an X server did the job, and I
vnc'd to it so qemu was running entirely locally on the machine with an
X connection.  Works at normal speed.

So how does one fix this, since the change in 6336 makes it rather
painful for those where SDL_Flip and company are inefficient.

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

Lennart Sorensen wrote:

> On Tue, Jan 20, 2009 at 06:09:33PM +0100, Samuel Thibault wrote:
>> Ah, that rings me a bell. There was problem with that, something like
>> now that sdl uses SDL_BlitSurface/SDL_Flip there is an X roundtrip,
>> which is awfully slow over ssh.  Would you be able to try without ssh?
> 
> That would be tricky since it is running on another machine.  I will
> try.  I do believe someone else said that they could confirm the slow
> behaviour with 6336 running locally as well.  It may be that some X
> drivers are slow at SDL_Flip and SDL_BlitSurface.
> 
> Hmm, my X server isn't compiled to allow tcp connections (only local
> sockets), so avoiding ssh looks hard too.
> 
> Maybe Xvnc can do it.  yeah Xvnc4 as an X server did the job, and I
> vnc'd to it so qemu was running entirely locally on the machine with an
> X connection.  Works at normal speed.
> 
> So how does one fix this, since the change in 6336 makes it rather
> painful for those where SDL_Flip and company are inefficient.
> 


At risk of being silly, why don't you just use vnc to connect to qemu,
if qemu is running on a remote machine?
Obviously sdl is optimized for the local case.

Of course if it is slow even locally, then there must be something wrong
somewhere either in qemu or in sdl.

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 06:16:59PM +0000, Stefano Stabellini wrote:
> At risk of being silly, why don't you just use vnc to connect to qemu,
> if qemu is running on a remote machine?
> Obviously sdl is optimized for the local case.

Well at the moment, openbios doesn't display when you use vnc by itself.
Someone else said they could confirm that, and it had something to do
with a display timer not being initialized.

> Of course if it is slow even locally, then there must be something wrong
> somewhere either in qemu or in sdl.

Well I wasn't the one that saw it slow locally.

Now does the change in 6336 make it faster on the local side for some
people?  if so, then I guess there is some potential there.

Is there some environment that can be set to tell SDL what driver to use
and how to behave?

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 01:25:48PM -0500, Lennart Sorensen wrote:
> On Tue, Jan 20, 2009 at 06:16:59PM +0000, Stefano Stabellini wrote:
> > At risk of being silly, why don't you just use vnc to connect to qemu,
> > if qemu is running on a remote machine?
> > Obviously sdl is optimized for the local case.
> 
> Well at the moment, openbios doesn't display when you use vnc by itself.
> Someone else said they could confirm that, and it had something to do
> with a display timer not being initialized.

Also doing alt-f# and control-w and such when using vnc is getting VERY
irretating, since vinegra takes control-w to mean close current
connection, while I want it sent through to delete work, or do other
things.  xvnc4viewer doesn't grab focus properly, and won't sent alt+f#
through, so my window manager still sees those.  All these work fine
with running it through a forwarded X connection, except the 6336 change
made that unusable.  VNC mode is a pain in the ass, although very
efficient protocol wise.

> > Of course if it is slow even locally, then there must be something wrong
> > somewhere either in qemu or in sdl.
> 
> Well I wasn't the one that saw it slow locally.
> 
> Now does the change in 6336 make it faster on the local side for some
> people?  if so, then I guess there is some potential there.
> 
> Is there some environment that can be set to tell SDL what driver to use
> and how to behave?

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Jamie Lokier]

Lennart Sorensen wrote:
> On Tue, Jan 20, 2009 at 01:25:48PM -0500, Lennart Sorensen wrote:
> > On Tue, Jan 20, 2009 at 06:16:59PM +0000, Stefano Stabellini wrote:
> > > At risk of being silly, why don't you just use vnc to connect to qemu,
> > > if qemu is running on a remote machine?
> > > Obviously sdl is optimized for the local case.
> > 
> > Well at the moment, openbios doesn't display when you use vnc by itself.
> > Someone else said they could confirm that, and it had something to do
> > with a display timer not being initialized.
> 
> Also doing alt-f# and control-w and such when using vnc is getting VERY
> irretating, since vinegra takes control-w to mean close current
> connection, while I want it sent through to delete work, or do other
> things.

You can switch Vinagre between full-keyboard mode and the mode where
it intercepts keys like control-W.  In the former mode, you can even
send Control-Alt-Del from the keyboard.  I agree it's annoying, but
much less so when you know how to do this (unfortunately the different
states aren't made obvious, and I don't remember how to switch them
right now).

Since I learned this, Vinagre got a lot nicer and I use VNC for all my
QEMU and KVM sessions now.  I got annoyed with SDL for other reasons,
and being able to detach from a running VM is quite nice.

-- Jamie

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 07:46:55PM +0000, Jamie Lokier wrote:
> You can switch Vinagre between full-keyboard mode and the mode where
> it intercepts keys like control-W.  In the former mode, you can even
> send Control-Alt-Del from the keyboard.  I agree it's annoying, but
> much less so when you know how to do this (unfortunately the different
> states aren't made obvious, and I don't remember how to switch them
> right now).
> 
> Since I learned this, Vinagre got a lot nicer and I use VNC for all my
> QEMU and KVM sessions now.  I got annoyed with SDL for other reasons,
> and being able to detach from a running VM is quite nice.

Seems vinagre is control-alt as it's grab/release keys, which of course
qemu does as well, so no wonder it's being hit and miss on working or
not.

Any way to change the qemu keystrokes?

Or I just have to find a better vnc client.

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Jamie Lokier]

Lennart Sorensen wrote:
> On Tue, Jan 20, 2009 at 07:46:55PM +0000, Jamie Lokier wrote:
> > You can switch Vinagre between full-keyboard mode and the mode where
> > it intercepts keys like control-W.  In the former mode, you can even
> > send Control-Alt-Del from the keyboard.  I agree it's annoying, but
> > much less so when you know how to do this (unfortunately the different
> > states aren't made obvious, and I don't remember how to switch them
> > right now).
> > 
> > Since I learned this, Vinagre got a lot nicer and I use VNC for all my
> > QEMU and KVM sessions now.  I got annoyed with SDL for other reasons,
> > and being able to detach from a running VM is quite nice.
> 
> Seems vinagre is control-alt as it's grab/release keys, which of course
> qemu does as well, so no wonder it's being hit and miss on working or
> not.
> 
> Any way to change the qemu keystrokes?

I don't think QEMU uses control-alt at all in VNC mode, does it?
I've never noticed it.
But I've always used a unix socket or stdin for the monitor; maybe
that makes a difference.

> Or I just have to find a better vnc client.

I used good old vncviewer for a while, until I found vncviewer can't
do full-screen on one monitor of a dual monitor setup.  Vinagre does
that quite nicely.  When I found out how to grab the keyboard properly
in Vinagre I found it pretty good for QEMU.  Being able to switch
between tabs to multiple VMs, and the bookmarks when you've got a few
VMs on the go, are quite nice too.

Some colleages used a Windows VNC client to a VM I'd set up, and that
just broke with QEMU.  (I don't remember which client.)  It displayed
the wrong colours, so there's still something amiss somewhere.

-- Jamie

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 08:12:39PM +0000, Jamie Lokier wrote:
> I don't think QEMU uses control-alt at all in VNC mode, does it?
> I've never noticed it.
> But I've always used a unix socket or stdin for the monitor; maybe
> that makes a difference.

I was running in X11 mode, using Xvnc4 as server and then running vnc to
that.  Now that I have a patch that makes qemu vnc mode actually work I
can do straight vnc and then the keystrokes are not a problem.

> I used good old vncviewer for a while, until I found vncviewer can't
> do full-screen on one monitor of a dual monitor setup.  Vinagre does
> that quite nicely.  When I found out how to grab the keyboard properly
> in Vinagre I found it pretty good for QEMU.  Being able to switch
> between tabs to multiple VMs, and the bookmarks when you've got a few
> VMs on the go, are quite nice too.
> 
> Some colleages used a Windows VNC client to a VM I'd set up, and that
> just broke with QEMU.  (I don't remember which client.)  It displayed
> the wrong colours, so there's still something amiss somewhere.

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

Lennart Sorensen wrote:

> On Tue, Jan 20, 2009 at 06:16:59PM +0000, Stefano Stabellini wrote:
>> At risk of being silly, why don't you just use vnc to connect to qemu,
>> if qemu is running on a remote machine?
>> Obviously sdl is optimized for the local case.
> 
> Well at the moment, openbios doesn't display when you use vnc by itself.
> Someone else said they could confirm that, and it had something to do
> with a display timer not being initialized.


I don't have a proper fix for that but if you apply the patch I attached
it should work.

If the gui_timer is not initialized qemu gets stuck in vl.c:main_loop
at the following line:

ret = cpu_exec(env);

maybe someone that works on qemu ppc emulation could help.


>> Of course if it is slow even locally, then there must be something wrong
>> somewhere either in qemu or in sdl.
> 
> Well I wasn't the one that saw it slow locally.
> 
> Now does the change in 6336 make it faster on the local side for some
> people?  if so, then I guess there is some potential there.



If you are using vnc and the guest uses 16 or 32 bpp it is faster; if
the guest is using another resolution it is as fast as before.

The sdl backend now uses sdl blitting functions to render the
framebuffer: the code is much cleaner but it may suffer a performance
loss if the guest does not use 16bpp or 32bpp (text mode for example).
Otherwise it is as fast as before (maybe even faster with some drivers).

I wasn't expecting the performance loss to be noticeable, I'll try to
come up with a clean improvement to the new interface.


> Is there some environment that can be set to tell SDL what driver to use
> and how to behave?
> 



SDL_VIDEODRIVER but usually it only works with x11, the default.


[-- Attachment #2: quick_fix --]
[-- Type: text/plain, Size: 630 bytes --]

diff --git a/vl.c b/vl.c
index 63d954b..2e84dce 100644
--- a/vl.c
+++ b/vl.c
@@ -5553,14 +5553,8 @@ int main(int argc, char **argv, char **envp)
     }
     dpy_resize(ds);
 
-    dcl = ds->listeners;
-    while (dcl != NULL) {
-        if (dcl->dpy_refresh != NULL) {
-            ds->gui_timer = qemu_new_timer(rt_clock, gui_update, ds);
-            qemu_mod_timer(ds->gui_timer, qemu_get_clock(rt_clock));
-        }
-        dcl = dcl->next;
-    }
+    ds->gui_timer = qemu_new_timer(rt_clock, gui_update, ds);
+    qemu_mod_timer(ds->gui_timer, qemu_get_clock(rt_clock));
 
     text_consoles_set_display(display_state);
 

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Tue, Jan 20, 2009 at 07:38:03PM +0000, Stefano Stabellini wrote:
> diff --git a/vl.c b/vl.c
> index 63d954b..2e84dce 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -5553,14 +5553,8 @@ int main(int argc, char **argv, char **envp)
>      }
>      dpy_resize(ds);
>  
> -    dcl = ds->listeners;
> -    while (dcl != NULL) {
> -        if (dcl->dpy_refresh != NULL) {
> -            ds->gui_timer = qemu_new_timer(rt_clock, gui_update, ds);
> -            qemu_mod_timer(ds->gui_timer, qemu_get_clock(rt_clock));
> -        }
> -        dcl = dcl->next;
> -    }
> +    ds->gui_timer = qemu_new_timer(rt_clock, gui_update, ds);
> +    qemu_mod_timer(ds->gui_timer, qemu_get_clock(rt_clock));
>  
>      text_consoles_set_display(display_state);
>  

That does seem to get vnc only mode to work.

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Avi Kivity]

Stefano Stabellini wrote:
> At risk of being silly, why don't you just use vnc to connect to qemu,
> if qemu is running on a remote machine?
>   

sdl over ssh is much easier to use than vnc.  I use it extensively while 
testing.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Samuel Thibault]

Lennart Sorensen, le Tue 20 Jan 2009 13:15:33 -0500, a écrit :
> Hmm, my X server isn't compiled to allow tcp connections (only local
> sockets), so avoiding ssh looks hard too.

Tcp or ssh would get the same kind of penalty: the network roundtrip
time.

Samuel

[Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

Lennart Sorensen wrote:

> I was trying to come up with a simple test case to show the problem,
> but found another one.  If I simply run qemu-system-ppc -vnc :1 I get
> nothing on VNC.  Using -sdl I get the openbios prompt.  If I use both
> -vnc :1 and -sdl I get openbios showing on both.  vnc by itself seems to
> only start displaying something once something other than openbios is
> running, like the bootloader or linux kernel.  That doesn't seem right.



I could reproduce this issue.
The problem seems to be strictly related to the gui_timer:

Currently we set the gui_timer only if someone implements dpy_refresh.
Since sdl implements dpy_refresh while vnc does not, when only vnc is
enabled the gui_timer is never allocated.

The weird thing is that even if I change the gui_update function to be
something like:

static void gui_update(void *opaque)
{
     uint64_t interval = GUI_REFRESH_INTERVAL;
     DisplayState *ds = opaque;
     DisplayChangeListener *dcl = ds->listeners;

     qemu_mod_timer(ds->gui_timer, interval + qemu_get_clock(rt_clock));
}

Vnc still works correctly.
So it doesn't matter the actual implementation of the function to be
called, as long as it is called.

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

Stefano Stabellini wrote:

> I could reproduce this issue.
> The problem seems to be strictly related to the gui_timer:
> 
> Currently we set the gui_timer only if someone implements dpy_refresh.
> Since sdl implements dpy_refresh while vnc does not, when only vnc is
> enabled the gui_timer is never allocated.
> 
> The weird thing is that even if I change the gui_update function to be
> something like:
> 
> static void gui_update(void *opaque)
> {
>      uint64_t interval = GUI_REFRESH_INTERVAL;
>      DisplayState *ds = opaque;
>      DisplayChangeListener *dcl = ds->listeners;
> 
>      qemu_mod_timer(ds->gui_timer, interval + qemu_get_clock(rt_clock));
> }
> 
> Vnc still works correctly.
> So it doesn't matter the actual implementation of the function to be
> called, as long as it is called.
> 

It seems that the select in vl.c:main_loop_wait never returns unless
gui_timer is properly set.
Something tells me that it shouldn't work this way :)

[Qemu-devel] Re: Extremely slow graphic updates

[Paul Brook]

> What is the quickest way for me to reproduce this problem?
> Have you seen this on ppc emulation only?
>
> I gather that the guest is in text mode. Have you seen this in graphical
> mode too? If yes, what was the resolution of the guest?

Steps to reproduce:
- Start qemu (doesn't matter which target or guest OS).
- Press c-a-2 to switch to the monitor.
- type "help<enter>"
- Watch the output slowly appear over the next 30 seconds

Running qemu over a forwarded X connection from a different machine (i.e. 
ssh -X) suffers a marked slowdown. With this configuration the early x86 boot 
stages are visibly much slower, in addition to the virtual console slowness 
mentioned above.

The monitor virtual console, VGA text mode and the graphical mode used by the 
knoppix bootloader[1] all show marked slowdown. It's unclear whether 
truecolor modes are effected.

[1] I'm guessing this is either VGA 16 color or VESA 256 color mode.

> What is the resolution of your host? What X11 extensions are you using?

I have reproduced on a couple of different machines. Both are fairly standard 
Debian sid installs, without any special Xorg config. One is x86, the other 
x86-64, both 32-bit color depth.
One nVidia FX5200(nv)@800x600, one ATI HD3470(radeonhd)@1600x1200.

> Do you set SDL_VIDEODRIVER anywhere?

No.

Paul

Re : [Qemu-devel] Re: Extremely slow graphic updates

[Sylvain Petreolle]

----- Message d'origine ----

> De : Paul Brook <paul@codesourcery.com>
> À : Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc : qemu-devel@nongnu.org; Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
> Envoyé le : Mardi, 20 Janvier 2009, 19h11mn 18s
> Objet : [Qemu-devel] Re: Extremely slow graphic updates
> 
> > What is the quickest way for me to reproduce this problem?
> > Have you seen this on ppc emulation only?
> >
> > I gather that the guest is in text mode. Have you seen this in graphical
> > mode too? If yes, what was the resolution of the guest?
> 
> Steps to reproduce:
> - Start qemu (doesn't matter which target or guest OS).
> - Press c-a-2 to switch to the monitor.
> - type "help"
> - Watch the output slowly appear over the next 30 seconds
> 
> Running qemu over a forwarded X connection from a different machine (i.e. 
> ssh -X) suffers a marked slowdown. With this configuration the early x86 boot 
> stages are visibly much slower, in addition to the virtual console slowness 
> mentioned above.
> 
> The monitor virtual console, VGA text mode and the graphical mode used by the 
> knoppix bootloader[1] all show marked slowdown. It's unclear whether 
> truecolor modes are effected.
> 
> [1] I'm guessing this is either VGA 16 color or VESA 256 color mode.
> 
> > What is the resolution of your host? What X11 extensions are you using?
> 
> I have reproduced on a couple of different machines. Both are fairly standard 
> Debian sid installs, without any special Xorg config. One is x86, the other 
> x86-64, both 32-bit color depth.
> One nVidia FX5200(nv)@800x600, one ATI HD3470(radeonhd)@1600x1200.
> 
> > Do you set SDL_VIDEODRIVER anywhere?
> 
> No.
> 
> Paul
I reproduce this issue also. 
All text mode part in the guest (x86) and the monitor are awfully slow.
I am running qemu locally, no SDL_VIDEODRIVER var is set and the video card is a ATI X1650

 Kind regards,
Sylvain Petreolle

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Stefan Weil]

Paul Brook schrieb:
>> What is the quickest way for me to reproduce this problem?
>> Have you seen this on ppc emulation only?
>>
>> I gather that the guest is in text mode. Have you seen this in graphical
>> mode too? If yes, what was the resolution of the guest?
>>     
>
> Steps to reproduce:
> - Start qemu (doesn't matter which target or guest OS).
> - Press c-a-2 to switch to the monitor.
> - type "help<enter>"
> - Watch the output slowly appear over the next 30 seconds
>
> Running qemu over a forwarded X connection from a different machine (i.e. 
> ssh -X) suffers a marked slowdown. With this configuration the early x86 boot 
> stages are visibly much slower, in addition to the virtual console slowness 
> mentioned above.
>
> The monitor virtual console, VGA text mode and the graphical mode used by the 
> knoppix bootloader[1] all show marked slowdown. It's unclear whether 
> truecolor modes are effected.
>
> [1] I'm guessing this is either VGA 16 color or VESA 256 color mode.
>
>   

I see a similar effect with the first serial console: booting a mips malta
linux kernel with debug output and a serial console took 15 s (up to
start of devfs),
now it takes 140 s with local SDL (estimated baud rate 600 or 1200 baud).
The serial console is only slow when it is selected.

VNC output or -nographic output is still fast.

Regards
Stefan Weil

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Paul Brook]

> Steps to reproduce:
> - Start qemu (doesn't matter which target or guest OS).
> - Press c-a-2 to switch to the monitor.
> - type "help<enter>"
> - Watch the output slowly appear over the next 30 seconds
>
> Running qemu over a forwarded X connection from a different machine (i.e.
> ssh -X) suffers a marked slowdown. With this configuration the early x86
> boot stages are visibly much slower, in addition to the virtual console
> slowness mentioned above.

I've applied a patch to fix this.

The problem was that we were incorrectly using SDL_Flip in sdl_update.

This is fundamentally wrong because the blit immediately above has only 
updated the recently changes section of the image. With a flipped surface the 
contents will be the frame before last (if not the one before that), so we'd 
actually need to blit everything that has changed in the last 2 (or 3) 
frames.

However we don't set SDL_DOUBLEBUFFER when SDL_SetVideoMode, so SDL_Flip this 
is just a confusing way of writing SDL_UpdateRect(real_screen, 0, 0, 0, 0); 
On systems where copying to the front buffer is expensive (in particular 
remote connections, or primitive Xorg drivers), needlessly refreshing the 
whole display has a huge effect on the cases mentioned above.

I've applied a patch to use the correct SDL_UpdateRect call instead.
This gets us almost back where we started. 

The virtual consoles are still slow over a remote connection. The text 
terminal code generates a lot of small redundant update. It appears that 
these now require an X server round trip, where they didn't before.
I'm not sure why, I can only guess that the blit rather than direct 
framebuffer access is foiling some internal SDL/X dirty region tracking.

Paul

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Wed, Jan 21, 2009 at 01:50:15AM +0000, Paul Brook wrote:
> > Steps to reproduce:
> > - Start qemu (doesn't matter which target or guest OS).
> > - Press c-a-2 to switch to the monitor.
> > - type "help<enter>"
> > - Watch the output slowly appear over the next 30 seconds
> >
> > Running qemu over a forwarded X connection from a different machine (i.e.
> > ssh -X) suffers a marked slowdown. With this configuration the early x86
> > boot stages are visibly much slower, in addition to the virtual console
> > slowness mentioned above.
> 
> I've applied a patch to fix this.
> 
> The problem was that we were incorrectly using SDL_Flip in sdl_update.
> 
> This is fundamentally wrong because the blit immediately above has only 
> updated the recently changes section of the image. With a flipped surface the 
> contents will be the frame before last (if not the one before that), so we'd 
> actually need to blit everything that has changed in the last 2 (or 3) 
> frames.
> 
> However we don't set SDL_DOUBLEBUFFER when SDL_SetVideoMode, so SDL_Flip this 
> is just a confusing way of writing SDL_UpdateRect(real_screen, 0, 0, 0, 0); 
> On systems where copying to the front buffer is expensive (in particular 
> remote connections, or primitive Xorg drivers), needlessly refreshing the 
> whole display has a huge effect on the cases mentioned above.
> 
> I've applied a patch to use the correct SDL_UpdateRect call instead.
> This gets us almost back where we started. 
> 
> The virtual consoles are still slow over a remote connection. The text 
> terminal code generates a lot of small redundant update. It appears that 
> these now require an X server round trip, where they didn't before.
> I'm not sure why, I can only guess that the blit rather than direct 
> framebuffer access is foiling some internal SDL/X dirty region tracking.

I just tried running with '-serial /dev/null -parallel /dev/null' and
the slow down problem disappeared.  I am suspicious of this part of the
6336 commit:

@@ -1360,12 +1352,137 @@ void qemu_console_copy(QEMUConsole *console, int src_x, int src_y,
                 int dst_x, int dst_y, int w, int h)
 {
     if (active_console == console) {
-        if (console->ds->dpy_copy)
-            console->ds->dpy_copy(console->ds,
-                            src_x, src_y, dst_x, dst_y, w, h);
-        else {
-            /* TODO */
-            console->ds->dpy_update(console->ds, dst_x, dst_y, w, h);
-        }
+            dpy_copy(console->ds, src_x, src_y, dst_x, dst_y, w, h);
     }
 }

To me this looks like what used to do a copy if the console was active,
and an update if it was not, has turned into a copy at all times.  This
sounds like potentially doing expensive work on inactive consoles.  This
is what made me think of trying to disable the parallel and serial
consoles.

I made this little patch for console.c:

--- qemu-0.9.1.14778c2064166a8d1d07b22f0af9eee4fa490e60/console.c       2009-01-21 09:26:06.000000000 -0500
+++ qemu-0.9.1.14778c2064166a8d1d07b22f0af9eee4fa490e60.new/console.c   2009-01-21 10:12:29.000000000 -0500
@@ -1433,7 +1433,11 @@
                        int dst_x, int dst_y, int w, int h)
 {
     if (is_graphic_console()) {
-        dpy_copy(ds, src_x, src_y, dst_x, dst_y, w, h);
+        if(active_console->ds == ds) {
+            dpy_copy(ds, src_x, src_y, dst_x, dst_y, w, h);
+        } else {
+            dpy_update(ds, dst_x, dst_y, w, h);
+        }
     }
 }

And then it is back to proper speed for me across ssh.  Does it make sense?

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

Lennart Sorensen wrote:

> I just tried running with '-serial /dev/null -parallel /dev/null' and
> the slow down problem disappeared.  I am suspicious of this part of the
> 6336 commit:
> 
> @@ -1360,12 +1352,137 @@ void qemu_console_copy(QEMUConsole *console, int src_x, int src_y,
>                  int dst_x, int dst_y, int w, int h)
>  {
>      if (active_console == console) {
> -        if (console->ds->dpy_copy)
> -            console->ds->dpy_copy(console->ds,
> -                            src_x, src_y, dst_x, dst_y, w, h);
> -        else {
> -            /* TODO */
> -            console->ds->dpy_update(console->ds, dst_x, dst_y, w, h);
> -        }
> +            dpy_copy(console->ds, src_x, src_y, dst_x, dst_y, w, h);
>      }
>  }
> 
> To me this looks like what used to do a copy if the console was active,
> and an update if it was not, has turned into a copy at all times.  This
> sounds like potentially doing expensive work on inactive consoles.  This
> is what made me think of trying to disable the parallel and serial
> consoles.
> 
> I made this little patch for console.c:
> 
> --- qemu-0.9.1.14778c2064166a8d1d07b22f0af9eee4fa490e60/console.c       2009-01-21 09:26:06.000000000 -0500
> +++ qemu-0.9.1.14778c2064166a8d1d07b22f0af9eee4fa490e60.new/console.c   2009-01-21 10:12:29.000000000 -0500
> @@ -1433,7 +1433,11 @@
>                         int dst_x, int dst_y, int w, int h)
>  {
>      if (is_graphic_console()) {
> -        dpy_copy(ds, src_x, src_y, dst_x, dst_y, w, h);
> +        if(active_console->ds == ds) {
> +            dpy_copy(ds, src_x, src_y, dst_x, dst_y, w, h);
> +        } else {
> +            dpy_update(ds, dst_x, dst_y, w, h);
> +        }
>      }
>  }
> 
> And then it is back to proper speed for me across ssh.  Does it make sense?
> 


I am afraid your patch shouldn't make a difference because sdl doesn't
have a dpy_copy function so with sdl dpy_update is always called.
Besides none calls qemu_console_copy but graphic cards so passing
'-serial /dev/null -parallel /dev/null' shouldn't change anything in
this regard.

In any case I tried passing '-serial /dev/null -parallel /dev/null' as
arguments but (locally) I do not see any benefits (I tested with the
debian ppc installation cd).
Could you please tell me if you see the slowdown on a local X server also?
The sdl blitting functions are optimized to be run locally, it is
possible that they do not have good performances on a remote X server.
Fortunately we provide a much better interface to connect to qemu
remotely (vnc), that now should be even faster than before.

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Wed, Jan 21, 2009 at 08:06:38PM +0000, Stefano Stabellini wrote:
> I am afraid your patch shouldn't make a difference because sdl doesn't
> have a dpy_copy function so with sdl dpy_update is always called.
> Besides none calls qemu_console_copy but graphic cards so passing
> '-serial /dev/null -parallel /dev/null' shouldn't change anything in
> this regard.
> 
> In any case I tried passing '-serial /dev/null -parallel /dev/null' as
> arguments but (locally) I do not see any benefits (I tested with the
> debian ppc installation cd).
> Could you please tell me if you see the slowdown on a local X server also?
> The sdl blitting functions are optimized to be run locally, it is
> possible that they do not have good performances on a remote X server.
> Fortunately we provide a much better interface to connect to qemu
> remotely (vnc), that now should be even faster than before.

No it is not slow locally.

Now can you explain why my patch made it no longer slow remotely because
it did fix the problem for me.  can you explain why changing -serial and
-parallel to /dev/null made it not slow?

So without my patch it runs fine locally.  It runs slow remotely.

With my patch it runs fine locally and remotely.

Without my patch but using -serial /dev/null -parallel /dev/null it runs
fine locally and remotely.

Something more than just a dpy_update must be happening in dpy_copy.
Looking at the code I don't quite see what it could be doing, unless
there is a long list of listeners initiallized some of which do have a
copy function.

So either my patch does something, or I have got my builds mixed up and
have some other patch in now that fixes it.  Maybe I will go do a fresh
checkout and build and test that then just to be sure.

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Wed, Jan 21, 2009 at 04:29:21PM -0500, Lennart Sorensen wrote:
> No it is not slow locally.
> 
> Now can you explain why my patch made it no longer slow remotely because
> it did fix the problem for me.  can you explain why changing -serial and
> -parallel to /dev/null made it not slow?
> 
> So without my patch it runs fine locally.  It runs slow remotely.
> 
> With my patch it runs fine locally and remotely.
> 
> Without my patch but using -serial /dev/null -parallel /dev/null it runs
> fine locally and remotely.
> 
> Something more than just a dpy_update must be happening in dpy_copy.
> Looking at the code I don't quite see what it could be doing, unless
> there is a long list of listeners initiallized some of which do have a
> copy function.
> 
> So either my patch does something, or I have got my builds mixed up and
> have some other patch in now that fixes it.  Maybe I will go do a fresh
> checkout and build and test that then just to be sure.

OK, must be my fault.  Seems it does run at proper speed with the
current git tree even with remote X over ssh.  So one of the other
patches recently must have fixed what caused the major slowness, or the
network here has had a drastic drop in network traffic (I doubt that).

Looks like it is OK now then.

-- 
Len Sorensen

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Stefano Stabellini]

Lennart Sorensen wrote:

> 
> OK, must be my fault.  Seems it does run at proper speed with the
> current git tree even with remote X over ssh.  So one of the other
> patches recently must have fixed what caused the major slowness, or the
> network here has had a drastic drop in network traffic (I doubt that).
> 
> Looks like it is OK now then.
> 


All for the best then :)
Thanks for testing anyway.

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Paul Brook]

> > So either my patch does something, or I have got my builds mixed up and
> > have some other patch in now that fixes it.  Maybe I will go do a fresh
> > checkout and build and test that then just to be sure.
>
> OK, must be my fault.  Seems it does run at proper speed with the
> current git tree even with remote X over ssh.  So one of the other
> patches recently must have fixed what caused the major slowness, or the
> network here has had a drastic drop in network traffic (I doubt that).

I fixed two things: 

r6373) Partial updates only update the effected area, not the whole screen. 
This effects both local and remote displays.

r6374) The virtual consoles coalesce multiple update regions into a single 
region. This tends to effect both local and remote displays.

If reverting the second patch "fixes" your problem then the bug is probably 
still latent. I just made the colsole code less dumb so that it doesn't 
matter so much in practice.

Paul

Re: [Qemu-devel] Re: Extremely slow graphic updates

[Lennart Sorensen]

On Thu, Jan 22, 2009 at 12:20:28AM +0000, Paul Brook wrote:
> I fixed two things: 
> 
> r6373) Partial updates only update the effected area, not the whole screen. 
> This effects both local and remote displays.
> 
> r6374) The virtual consoles coalesce multiple update regions into a single 
> region. This tends to effect both local and remote displays.
> 
> If reverting the second patch "fixes" your problem then the bug is probably 
> still latent. I just made the colsole code less dumb so that it doesn't 
> matter so much in practice.

As long as ssh -X over 100mbit is fast enough not to cause a problem, I
am OK with it.

I think part of the slowdown may also have to do with the lack of a
timer in ppc emulation (and some others) which is being discussed by
people that actually know what that means. :)

-- 
Len Sorensen