[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] TCG PPC performance regression?
From: |
Mark Cave-Ayland |
Subject: |
Re: [Qemu-ppc] TCG PPC performance regression? |
Date: |
Tue, 06 Mar 2012 16:56:14 +0000 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20120207 Icedove/3.0.11 |
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.