Re: [Qemu-ppc] TCG PPC performance regression?

[Alexander Graf]

On 06.03.2012, at 17:56, Mark Cave-Ayland <address@hidden> wrote:

> On 06/03/12 16:30, Mark Cave-Ayland wrote:
> 
>> I think I might try generating some gprof profiles to see if I can find
>> out where the time is going.
> 
> Now these are lot more interesting: firstly here is the top of the profile 
> from commit 2dd3022826bb1ced27d12493a8f1f4b6d4bc71b7 which works at the old 
> (fast) speed:
> 
> 
> Each sample counts as 0.01 seconds.
>  %   cumulative   self              self     total
> time   seconds   seconds    calls   s/call   s/call  name
> 13.16      1.27     1.27 119426766     0.00     0.00  tb_find_fast
>  9.74      2.21     0.94    24710     0.00     0.00  cpu_ppc_exec
>  6.53      2.84     0.63 123879339     0.00     0.00  temp_save
>  3.52      3.18     0.34 119426766     0.00     0.00  cpu_get_tb_cpu_state
>  3.32      3.50     0.32 34593698     0.00     0.00  stl_data
>  3.21      3.81     0.31 128381635     0.00     0.00 tb_jmp_cache_hash_func
>  3.21      4.12     0.31  8957486     0.00     0.00  tb_find_slow
>  2.64      4.38     0.26 119426766     0.00     0.00  spin_lock
>  2.38      4.61     0.23    54332     0.00     0.00  tlb_flush
>  2.07      4.81     0.20                             __ldw_mmu
> 
> 
> Compare this with the same from current git master 
> (da71ebd1450fcf6f0c424810a37ec6abee02a22b):
> 
> 
> Each sample counts as 0.01 seconds.
>  %   cumulative   self              self     total
> time   seconds   seconds    calls   s/call   s/call  name
>  8.37      0.19     0.19 15252000     0.00     0.00  test_and_clear_bit
>  7.71      0.37     0.18   444241     0.00     0.00  qemu_iohandler_fill
>  6.17      0.51     0.14      423     0.00     0.00 vnc_refresh_server_surface
>  5.95      0.64     0.14   461051     0.00     0.00  qemu_bh_poll
>  5.73      0.77     0.13   444241     0.00     0.00  main_loop_wait
>  5.73      0.90     0.13   444241     0.00     0.00  qemu_iohandler_poll
>  5.73      1.03     0.13   444241     0.00     0.00  slirp_select_poll
>  4.85      1.14     0.11    25778     0.00     0.00  vga_draw_line15_32
>  3.96      1.23     0.09 20622400     0.00     0.00  lduw_be_p
>  3.52      1.31     0.08   444241     0.00     0.00  slirp_select_fill
>  3.08      1.38     0.07   130055     0.00     0.00  qemu_cpu_kick_thread
>  2.64      1.44     0.06   444241     0.00     0.00  qemu_run_all_timers
>  2.64      1.50     0.06  1332723     0.00     0.00  qemu_run_timers
>  2.20      1.55     0.05   112306     0.00     0.00  qemu_mutex_lock
>  2.20      1.60     0.05   132483     0.00     0.00 qemu_mutex_lock_iothread
>  1.76      1.64     0.04 20622400     0.00     0.00  rgb_to_pixel32
>  1.76      1.68     0.04   444241     0.00     0.00  glib_select_fill
>  1.76      1.72     0.04   263692     0.00     0.00  clear_bit
>  1.76      1.76     0.04   204285     0.00     0.00  dynticks_rearm_timer
>  1.76      1.80     0.04        1     0.04     2.06  main_loop
>  1.32      1.83     0.03   444241     0.00     0.00  main_loop_should_exit
>  1.32      1.86     0.03   204288     0.00     0.00 qemu_next_alarm_deadline
>  1.32      1.89     0.03   204286     0.00     0.00 qemu_rearm_alarm_timer
> 
> 
> This looks strongly to me as if something is causing the VGA framebuffer to 
> update over-aggressively which is causing the slowdown. And it would explain 
> why HelenOS is slow as to be unusable because it has animated graphics on its 
> main screen :(
> 
> Does anyone know who the current maintainer of the VNC/VGA framebuffer update 
> code is? I can't see any one person listed in MAINTAINERS. Or should I just 
> raise a separate thread on qemu-devel?

Yes, please do so :)

Alex