[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] Profiling results

From: BALATON Zoltan
Subject: Re: [Qemu-ppc] Profiling results
Date: Tue, 17 Jul 2018 21:35:30 +0200 (CEST)
User-agent: Alpine 2.21 (BSF 202 2017-01-01)

On Tue, 17 Jul 2018, Mark Cave-Ayland wrote:
MorphOS on mac99 this seems to be significant. This is with default configure (--enable-qom-cast-debug):

%?????? cum. %???? linenr info???????????????? symbol name
9.7057?? 9.7057??? exec-all.h:410????????????? helper_lookup_tb_ptr
8.0330? 17.7387??? object.c:711 object_class_dynamic_cast_assert
6.9411? 24.6798??? cputlb.c:793??????????????? io_readx
6.3219? 31.0017??? sm501_template.h:62???????? draw_line16_32
5.3601? 36.3617??? cputlb.c:114??????????????? tlb_flush_nocheck
3.6170? 39.9787??? translate-all.c:749???????? page_trylock_add
3.1188? 43.0975??? translate-all.c:803???????? page_collection_lock
3.0405? 46.1380??? exec.c:3025???????????????? iotlb_to_section
2.7044? 48.8424??? softmmu_template.h:112????? helper_ret_ldub_mmu
2.4154? 51.2578??? memory.c:1350?????????????? memory_region_access_valid
My first thought is that there is a QOM cast somewhere in a hot path on -M mac99 - can you show us the call stack information from the profile?

Not really. Oprofile that gave me this profile could not display call graph for this call. I've tried again with the perf tool but I'm not quite sure how to interpret its results. If I'm not mistaken it points me in the direction of cpu_asidx_from_attrs, called from iotlb_to_section, called from io_readx. The object_class_dynamic_cast_assert call likely comes from OBJECT_CLASS_CHECK, expanded from OBJECT_GET_CLASS, expanded from CPU_GET_CLASS. Would that make any sense? Any idea what to do about it?

Thank you,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]