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

[Mark Cave-Ayland]

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?


ATB,

Mark.