Perf сообщает о некоторых инструкциях прямого перехода в качестве инструкций доступа к памяти - PullRequest
1 голос
/ 18 января 2020

Я использовал следующую команду perf, чтобы сэмплировать доступы чтения из пространства пользователя к DRAM с помощью evince:

perf record -d --call-graph dwarf -c 100 -e mem_load_uops_retired.l3_miss:uppp /opt/evince-3.28.4/bin/evince

Как видно, я использовал функцию PEBS для повышения точности выборки. , Но есть некоторые обращения без памяти, о которых сообщают как о доступах памяти. Например, это событие выборки, сообщаемое perf script:

evince 20589 16079.401401:        100 mem_load_uops_retired.l3_miss:uppp:     555555860750         5080022 N/A|SNP N/A|TLB N/A|LCK N/A
    555555579939 ev_history_can_go_back+0x19 (/opt/evince-3.28.4/bin/evince)
    5555555862ef ev_window_update_actions_sensitivity+0xa1f (/opt/evince-3.28.4/bin/evince)
    55555558ce4f ev_window_page_changed_cb+0xf (/opt/evince-3.28.4/bin/evince)
    7ffff574510c g_closure_invoke+0x19c (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff575805d signal_emit_unlocked_R+0xf4d (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff5760714 g_signal_emit_valist+0xa74 (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff576112e g_signal_emit+0x8e (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff7140d76 emit_value_changed+0xf6 (inlined)
    7ffff7140d76 adjustment_set_value+0xf6 (inlined)
    7ffff7140d76 gtk_adjustment_set_value_internal+0xf6 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff574510c g_closure_invoke+0x19c (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff5757de7 signal_emit_unlocked_R+0xcd7 (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff575fc7f g_signal_emitv+0x27f (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff7153519 gtk_binding_entry_activate+0x289 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff71539ef binding_activate+0x5f (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff7153b7f gtk_bindings_activate_list+0x17f (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff7154cd8 gtk_bindings_activate_event+0x98 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff7973959 ev_view_key_press_event+0x59 (/opt/evince-3.28.4/lib/libevview3.so.3.0.0)
    7ffff72698f6 _gtk_marshal_BOOLEAN__BOXEDv+0xa6 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff574524f _g_closure_invoke_va+0xbf (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff57603cc g_signal_emit_valist+0x72c (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff576112e g_signal_emit+0x8e (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff73b1533 gtk_widget_event_internal+0x163 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff73d1f0a gtk_window_propagate_key_event+0xfa (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    5555555894b1 ev_window_key_press_event+0x31 (/opt/evince-3.28.4/bin/evince)
    7ffff72698f6 _gtk_marshal_BOOLEAN__BOXEDv+0xa6 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff5745345 _g_closure_invoke_va+0x1b5 (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff57603cc g_signal_emit_valist+0x72c (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff576112e g_signal_emit+0x8e (/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.5600.4)
    7ffff73b1533 gtk_widget_event_internal+0x163 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff726693e propagate_event+0x21e (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff7268947 gtk_main_do_event+0x7f7 (/usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2200.30)
    7ffff6d79764 _gdk_event_emit+0x24 (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.2200.30)
    7ffff6da9f91 gdk_event_source_dispatch+0x21 (/usr/lib/x86_64-linux-gnu/libgdk-3.so.0.2200.30)
    7ffff546a416 g_main_dispatch+0x2e6 (inlined)
    7ffff546a416 g_main_context_dispatch+0x2e6 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
    7ffff546a64f g_main_context_iterate+0x1ff (inlined)
    7ffff546a6db g_main_context_iteration+0x2b (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.4)
    7ffff5a2be3c g_application_run+0x1fc (/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.5600.4)
    555555573707 main+0x447 (/opt/evince-3.28.4/bin/evince)
    7ffff4a91b96 __libc_start_main+0xe6 (/lib/x86_64-linux-gnu/libc-2.27.so)
    555555573899 _start+0x29 (/opt/evince-3.28.4/bin/evince)
ffffffffffffffff [unknown] ([unknown])

Это означает, что существует доступ к адресу 0x555555860750 (который находится в [heap]) по инструкции на 0x555555579939 (который расположен в секции evince text со смещением 0x19 функции ev_history_can_go_back()). Эта инструкция по памяти является последней строкой в ​​следующем фрагменте кода:

0000000000025920 <ev_history_can_go_back>:
   25920:       53                      push   %rbx
   25921:       48 89 fb                mov    %rdi,%rbx
   25924:       e8 67 fa ff ff          callq  25390 <ev_history_get_type>
   25929:       48 85 db                test   %rbx,%rbx
   2592c:       74 42                   je     25970 <ev_history_can_go_back+0x50>
   2592e:       48 8b 13                mov    (%rbx),%rdx
   25931:       48 85 d2                test   %rdx,%rdx
   25934:       74 05                   je     2593b <ev_history_can_go_back+0x1b>
   25936:       48 39 02                cmp    %rax,(%rdx)
   25939:       74 0f                   je     2594a <ev_history_can_go_back+0x2a>

Это переход к ev_history_can_go_back+0x2a и, по-видимому, это не доступ к [heap] по адресу 0x555555860750. Это perf отчет неверный?

1 Ответ

5 голосов
/ 19 января 2020

По крайней мере, на процессорах Intel cmp %rax,(%rdx) может слиться макросом со следующими значениями je, в то же время микросжигая нагрузку. https://agner.org/optimize/. Также относится: Режимы микроплавления и адресации (это неиндексированный режим адресации, поэтому он может оставаться микрослитым даже в Sandybridge / IvyBridge).

То есть в переплавленном домен (где происходит выход из строя) у вас действительно есть одиночное сравнение и ветвление с источником памяти. Обратите внимание, что mem_load_uops_retired.l3_miss:uppp считает количество мопов, а не инструкций.

Даже в неиспользованном домене, macro -fused сравнивать / ветвление действительно выполняется как один моп на одном исполнительном модуле, но загрузка должна выполняться на отдельном порту. (Micro-Fusion экономит полосу пропускания декодирования / выдачи и объем кэша UOP, но не порты на стороне сервера.)

...