On 17/07/18 20:35, BALATON Zoltan wrote:
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?
Good question. A quick grep for 'asidx_from_attrs' shows that
cc->asidx_from_attrs() isn't set for PPC targets, so as a quick test
does replacing the inline function cpu_asidx_from_attrs() in
include/qom/cpu.h with a simple "return 0" change the profile at all?
ATB,
Mark.