1. 09 Feb, 2024 1 commit
    • Yang Jihong's avatar
      perf sched: Move start_work_mutex and work_done_wait_mutex initialization to perf_sched__replay() · c6907863
      Yang Jihong authored
      The start_work_mutex and work_done_wait_mutex are used only for the
      'perf sched replay'. Put their initialization in perf_sched__replay () to
      reduce unnecessary actions in other commands.
      
      Simple functional testing:
      
        # perf sched record perf bench sched messaging
        # Running 'sched/messaging' benchmark:
        # 20 sender and receiver processes per group
        # 10 groups == 400 processes run
      
             Total time: 0.197 [sec]
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 14.952 MB perf.data (134165 samples) ]
      
        # perf sched replay
        run measurement overhead: 108 nsecs
        sleep measurement overhead: 65658 nsecs
        the run test took 999991 nsecs
        the sleep test took 1079324 nsecs
        nr_run_events:        42378
        nr_sleep_events:      43102
        nr_wakeup_events:     31852
        target-less wakeups:  17
        multi-target wakeups: 712
        task      0 (             swapper:         0), nr_events: 10451
        task      1 (             swapper:         1), nr_events: 3
        task      2 (             swapper:         2), nr_events: 1
        <SNIP>
        task    717 (     sched-messaging:     74483), nr_events: 152
        task    718 (     sched-messaging:     74484), nr_events: 1944
        task    719 (     sched-messaging:     74485), nr_events: 73
        task    720 (     sched-messaging:     74486), nr_events: 163
        task    721 (     sched-messaging:     74487), nr_events: 942
        task    722 (     sched-messaging:     74488), nr_events: 78
        task    723 (     sched-messaging:     74489), nr_events: 1090
        ------------------------------------------------------------
        #1  : 1366.507, ravg: 1366.51, cpu: 7682.70 / 7682.70
        #2  : 1410.072, ravg: 1370.86, cpu: 7723.88 / 7686.82
        #3  : 1396.296, ravg: 1373.41, cpu: 7568.20 / 7674.96
        #4  : 1381.019, ravg: 1374.17, cpu: 7531.81 / 7660.64
        #5  : 1393.826, ravg: 1376.13, cpu: 7725.25 / 7667.11
        #6  : 1401.581, ravg: 1378.68, cpu: 7594.82 / 7659.88
        #7  : 1381.337, ravg: 1378.94, cpu: 7371.22 / 7631.01
        #8  : 1373.842, ravg: 1378.43, cpu: 7894.92 / 7657.40
        #9  : 1364.697, ravg: 1377.06, cpu: 7324.91 / 7624.15
        #10 : 1363.613, ravg: 1375.72, cpu: 7209.55 / 7582.69
        # echo $?
        0
      Signed-off-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240206083228.172607-2-yangjihong1@huawei.com
      c6907863
  2. 08 Feb, 2024 3 commits
    • Yicong Yang's avatar
      perf test: Skip metric w/o event name on arm64 in stat STD output linter · 5f70c6c5
      Yicong Yang authored
      stat+std_output.sh test fails on my arm64 machine:
      [root@localhost shell]# ./stat+std_output.sh
      Checking STD output: no args Unknown event name in TopDownL1                 #     0.18 retiring
      [root@localhost shell]# ./stat+std_output.sh
      Checking STD output: no args [Success]
      Checking STD output: system wide [Success]
      Checking STD output: interval [Success]
      Checking STD output: per thread Unknown event name in tmux: server-1114960                                                   #     0.41 frontend_bound
      
      When no args specified `perf stat` will add TopdownL1 metric group
      and the output will be like:
      [root@localhost shell]# perf stat -- stress-ng --vm 1 --timeout 1
      stress-ng: info:  [3351733] setting to a 1 second run per stressor
      stress-ng: info:  [3351733] dispatching hogs: 1 vm
      stress-ng: info:  [3351733] successful run completed in 1.02s
      
       Performance counter stats for 'stress-ng --vm 1 --timeout 1':
      
                1,037.71 msec task-clock                       #    1.000 CPUs utilized
                      13      context-switches                 #   12.528 /sec
                       1      cpu-migrations                   #    0.964 /sec
                  67,544      page-faults                      #   65.090 K/sec
           2,691,932,561      cycles                           #    2.594 GHz                         (74.56%)
           6,571,333,653      instructions                     #    2.44  insn per cycle              (74.92%)
             521,863,142      branches                         #  502.901 M/sec                       (75.21%)
                 425,879      branch-misses                    #    0.08% of all branches             (87.57%)
                              TopDownL1                 #     0.61 retiring                    (87.67%)
                                                        #     0.03 frontend_bound              (87.67%)
                                                        #     0.02 bad_speculation             (87.67%)
                                                        #     0.34 backend_bound               (74.61%)
      
             1.038138390 seconds time elapsed
      
             0.844849000 seconds user
             0.189053000 seconds sys
      
      Metrics in group TopDownL1 don't have event name on arm64 but are not
      listed in the $skip_metric list which they should be listed. Add them
      to the skip list as what does for x86 platforms in [1].
      
      [1] commit 4d60e83d ("perf test: Skip metrics w/o event name in stat STD output linter")
      Signed-off-by: default avatarYicong Yang <yangyicong@hisilicon.com>
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: linuxarm@huawei.com
      Cc: kan.liang@linux.intel.com
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240207091222.54096-1-yangyicong@huawei.com
      5f70c6c5
    • Adrian Hunter's avatar
      perf symbols: Slightly improve module file executable section mappings · 94a830d7
      Adrian Hunter authored
      Currently perf does not record module section addresses except for
      the .text section. In general that means perf cannot get module section
      mappings correct (except for .text) when loading symbols from a kernel
      module file. (Note using --kcore does not have this issue)
      
      Improve that situation slightly by identifying executable sections that
      use the same mapping as the .text section. That happens when an
      executable section comes directly after the .text section, both in memory
      and on file, something that can be determined by following the same layout
      rules used by the kernel, refer kernel layout_sections(). Note whether
      that happens is somewhat arbitrary, so this is not a final solution.
      
      Example from tracing a virtual machine process:
      
       Before:
      
        $ perf script | grep unknown
               CPU 0/KVM    1718   203.511270:     318341 cpu-cycles:P:  ffffffffc13e8a70 [unknown] (/lib/modules/6.7.2-local/kernel/arch/x86/kvm/kvm-intel.ko)
        $ perf script -vvv 2>&1 >/dev/null | grep kvm.intel | grep 'noinstr.text\|ffff'
        Map: 0-7e0 41430 [kvm_intel].noinstr.text
        Map: ffffffffc13a7000-ffffffffc1421000 a0 /lib/modules/6.7.2-local/kernel/arch/x86/kvm/kvm-intel.ko
      
       After:
      
        $ perf script | grep 203.511270
               CPU 0/KVM    1718   203.511270:     318341 cpu-cycles:P:  ffffffffc13e8a70 vmx_vmexit+0x0 (/lib/modules/6.7.2-local/kernel/arch/x86/kvm/kvm-intel.ko)
        $ perf script -vvv 2>&1 >/dev/null | grep kvm.intel | grep 'noinstr.text\|ffff'
        Map: ffffffffc13a7000-ffffffffc1421000 a0 /lib/modules/6.7.2-local/kernel/arch/x86/kvm/kvm-intel.ko
      Reported-by: default avatarLike Xu <like.xu.linux@gmail.com>
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240208085326.13432-3-adrian.hunter@intel.com
      94a830d7
    • Adrian Hunter's avatar
      perf tools: Make it possible to see perf's kernel and module memory mappings · 0bdfbd04
      Adrian Hunter authored
      Dump kmaps if using 'perf --debug kmaps' or verbose > 2 (e.g. -vvv) for
      tools 'perf script' and 'perf report' if there is no browser.
      
      Example:
      
        $ perf --debug kmaps script 2>&1 >/dev/null | grep kvm.intel
        build id event received for /lib/modules/6.7.2-local/kernel/arch/x86/kvm/kvm-intel.ko: 0691d75e10e72ebbbd45a44c59f6d00a5604badf [20]
        Map: 0-3a3 4f5d8 [kvm_intel].modinfo
        Map: 0-5240 5f280 [kvm_intel]__versions
        Map: 0-30 64 [kvm_intel].note.Linux
        Map: 0-14 644c0 [kvm_intel].orc_header
        Map: 0-5297 43680 [kvm_intel].rodata
        Map: 0-5bee 3b837 [kvm_intel].text.unlikely
        Map: 0-7e0 41430 [kvm_intel].noinstr.text
        Map: 0-2080 713c0 [kvm_intel].bss
        Map: 0-26 705c8 [kvm_intel].data..read_mostly
        Map: 0-5888 6a4c0 [kvm_intel].data
        Map: 0-22 70220 [kvm_intel].data.once
        Map: 0-40 705f0 [kvm_intel].data..percpu
        Map: 0-1685 41d20 [kvm_intel].init.text
        Map: 0-4b8 6fd60 [kvm_intel].init.data
        Map: 0-380 70248 [kvm_intel]__dyndbg
        Map: 0-8 70218 [kvm_intel].exit.data
        Map: 0-438 4f980 [kvm_intel]__param
        Map: 0-5f5 4ca0f [kvm_intel].rodata.str1.1
        Map: 0-3657 493b8 [kvm_intel].rodata.str1.8
        Map: 0-e0 70640 [kvm_intel].data..ro_after_init
        Map: 0-500 70ec0 [kvm_intel].gnu.linkonce.this_module
        Map: ffffffffc13a7000-ffffffffc1421000 a0 /lib/modules/6.7.2-local/kernel/arch/x86/kvm/kvm-intel.ko
      
      The example above shows how the module section mappings are all wrong
      except for the main .text mapping at 0xffffffffc13a7000.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Like Xu <like.xu.linux@gmail.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240208085326.13432-2-adrian.hunter@intel.com
      0bdfbd04
  3. 07 Feb, 2024 3 commits
    • Namhyung Kim's avatar
      perf record: Display data size on pipe mode · 5b9e4eef
      Namhyung Kim authored
      Currently pipe mode doesn't set the file size and it results in a
      misleading message of 0 data size at the end.  Although it might miss
      some accounting for pipe header or more, just displaying the data size
      would reduce the possible confusion.
      
      Before:
        $ perf record -o- perf test -w noploop | perf report -i- -q --percent-limit=1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.000 MB - ]    <======  (here)
            99.58%  perf     perf                  [.] noploop
      
      After:
        $ perf record -o- perf test -w noploop | perf report -i- -q --percent-limit=1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.229 MB - ]
            99.46%  perf     perf                  [.] noploop
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Link: https://lore.kernel.org/r/20240112231340.779469-1-namhyung@kernel.org
      5b9e4eef
    • Kan Liang's avatar
      perf script: Print source line for each jump in brstackinsn · 112c5547
      Kan Liang authored
      With the srcline option, the perf script only prints a source line at
      the beginning of a sample with call/ret from functions, but not for
      each jump in brstackinsn. It's useful to print a source line for each
      jump in brstackinsn when the end user analyze the full assembler
      sequences of branch sequences for the sample.
      
      The srccode option can also be used to locate the source code line.
      However, it's printed almost for every line and makes the output less
      readable.
      
       $perf script -F +brstackinsn,+srcline --xed
      
      Before the patch,
      
       tchain_edit_deb 1463275 15228549.107820:     282495 instructions:u:            401133 f3+0xd (/home/kan/os.li>
        tchain_edit.c:22
              f3+40:  tchain_edit.c:20
              000000000040114e                        jle 0x401133                    # PRED 6 cycles [6]
              0000000000401133                        movl  -0x4(%rbp), %eax
              0000000000401136                        and $0x1, %eax
              0000000000401139                        test %eax, %eax
              000000000040113b                        jz 0x401143
              000000000040113d                        addl  $0x1, -0x4(%rbp)
              0000000000401141                        jmp 0x401147                    # PRED 3 cycles [9] 2.00 IPC
              0000000000401147                        cmpl  $0x3e7, -0x4(%rbp)
              000000000040114e                        jle 0x401133                    # PRED 6 cycles [15] 0.33 IPC
      
      After the patch,
      
       tchain_edit_deb 1463275 15228549.107820:     282495 instructions:u:            401133 f3+0xd (/home/kan/os.li>
        tchain_edit.c:22
              f3+40:  tchain_edit.c:20
              000000000040114e                        jle 0x401133                     srcline: tchain_edit.c:20      # PRED 6 cycles [6]
              0000000000401133                        movl  -0x4(%rbp), %eax
              0000000000401136                        and $0x1, %eax
              0000000000401139                        test %eax, %eax
              000000000040113b                        jz 0x401143
              000000000040113d                        addl  $0x1, -0x4(%rbp)
              0000000000401141                        jmp 0x401147                     srcline: tchain_edit.c:23      # PRED 3 cycles [9] 2.00 IPC
              0000000000401147                        cmpl  $0x3e7, -0x4(%rbp)
              000000000040114e                        jle 0x401133                     srcline: tchain_edit.c:20      # PRED 6 cycles [15] 0.33 IPC
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: ahmad.yasin@intel.com
      Cc: amiri.khalil@intel.com
      Cc: ak@linux.intel.com
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240205145819.1943114-1-kan.liang@linux.intel.com
      112c5547
    • Ian Rogers's avatar
      perf kvm powerpc: Fix build · 8ce5fa4d
      Ian Rogers authored
      Updates to struct parse_events_error needed to be carried through to
      PowerPC specific event parsing.
      
      Fixes: fd7b8e8f ("perf parse-events: Print all errors")
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarIan Rogers <irogers@google.com>
      Acked-by: default avatarNamhyung <namhyung@kernel.org>
      Cc: James Clark <james.clark@arm.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240206235902.2917395-1-irogers@google.com
      8ce5fa4d
  4. 06 Feb, 2024 1 commit
  5. 03 Feb, 2024 2 commits
  6. 02 Feb, 2024 9 commits
  7. 25 Jan, 2024 2 commits
  8. 24 Jan, 2024 10 commits
  9. 23 Jan, 2024 4 commits
  10. 22 Jan, 2024 5 commits
    • Yang Jihong's avatar
      perf data: Minor code style alignment cleanup · 57c8f107
      Yang Jihong authored
      Minor code style alignment cleanup for perf_data__switch() and
      perf_data__write().
      
      No functional change.
      Signed-off-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240119040304.3708522-4-yangjihong1@huawei.comSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      57c8f107
    • Yang Jihong's avatar
      perf record: Check conflict between '--timestamp-filename' option and pipe mode before recording · 02f9b50e
      Yang Jihong authored
      In pipe mode, no need to switch perf data output, therefore,
      '--timestamp-filename' option should not take effect.
      Check the conflict before recording and output WARNING.
      In this case, the check pipe mode in perf_data__switch() can be removed.
      
      Before:
      
        # perf record --timestamp-filename -o- perf test -w noploop | perf report -i- --percent-limit=1
        # To display the perf.data header info, please use --header/--header-only options.
        #
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Dump -.2024011812110182 ]
        #
        # Total Lost Samples: 0
        #
        # Samples: 4K of event 'cycles:P'
        # Event count (approx.): 2176784359
        #
        # Overhead  Command  Shared Object         Symbol
        # ........  .......  ....................  ......................................
        #
            97.83%  perf     perf                  [.] noploop
      
        #
        # (Tip: Print event counts in CSV format with: perf stat -x,)
        #
      
      After:
      
        # perf record --timestamp-filename -o- perf test -w noploop | perf report -i- --percent-limit=1
        WARNING: --timestamp-filename option is not available in pipe mode.
        # To display the perf.data header info, please use --header/--header-only options.
        #
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.000 MB - ]
        #
        # Total Lost Samples: 0
        #
        # Samples: 4K of event 'cycles:P'
        # Event count (approx.): 2185575421
        #
        # Overhead  Command  Shared Object          Symbol
        # ........  .......  .....................  .............................................
        #
            97.75%  perf     perf                   [.] noploop
      
        #
        # (Tip: Profiling branch (mis)predictions with: perf record -b / perf report)
        #
      
      Fixes: ecfd7a9c ("perf record: Add '--timestamp-filename' option to append timestamp to output file name")
      Signed-off-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240119040304.3708522-3-yangjihong1@huawei.comSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      02f9b50e
    • Yang Jihong's avatar
      perf record: Fix possible incorrect free in record__switch_output() · aff10a16
      Yang Jihong authored
      perf_data__switch() may not assign a legal value to 'new_filename'.
      In this case, 'new_filename' uses the on-stack value, which may cause a
      incorrect free and unexpected result.
      
      Fixes: 03724b2e ("perf record: Allow to limit number of reported perf.data files")
      Signed-off-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240119040304.3708522-2-yangjihong1@huawei.comSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      aff10a16
    • Namhyung Kim's avatar
      perf dwarf-aux: Check allowed DWARF Ops · 55442cc2
      Namhyung Kim authored
      The DWARF location expression can be fairly complex and it'd be hard
      to match it with the condition correctly.  So let's be conservative
      and only allow simple expressions.  For now it just checks the first
      operation in the list.  The following operations looks ok:
      
       * DW_OP_stack_value
       * DW_OP_deref_size
       * DW_OP_deref
       * DW_OP_piece
      
      To refuse complex (and unsupported) location expressions, add
      check_allowed_ops() to compare the rest of the list.  It seems earlier
      result contained those unsupported expressions.  For example, I found
      some local struct variable is placed like below.
      
       <2><43d1517>: Abbrev Number: 62 (DW_TAG_variable)
          <43d1518>   DW_AT_location    : 15 byte block: 91 50 93 8 91 78 93 4 93 84 8 91 68 93 4
              (DW_OP_fbreg: -48; DW_OP_piece: 8;
               DW_OP_fbreg: -8; DW_OP_piece: 4;
               DW_OP_piece: 1028;
               DW_OP_fbreg: -24; DW_OP_piece: 4)
      
      Another example is something like this.
      
          0057c8be ffffffffffffffff ffffffff812109f0 (base address)
          0057c8ce ffffffff812112b5 ffffffff812112c8 (DW_OP_breg3 (rbx): 0;
                                                      DW_OP_constu: 18446744073709551612;
                                                      DW_OP_and;
                                                      DW_OP_stack_value)
      
      It should refuse them.  After the change, the stat shows:
      
        Annotate data type stats:
        total 294, ok 158 (53.7%), bad 136 (46.3%)
        -----------------------------------------------------------
                30 : no_sym
                32 : no_mem_ops
                53 : no_var
                14 : no_typeinfo
                 7 : bad_offset
      Acked-by: default avatarMasami Hiramatsu (Google) <mhiramat@kernel.org>
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lore.kernel.org/r/20240117062657.985479-10-namhyung@kernel.orgSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      55442cc2
    • Namhyung Kim's avatar
      perf annotate-data: Support stack variables · bc10db8e
      Namhyung Kim authored
      Local variables are allocated in the stack and the location list
      should look like base register(s) and an offset.  Extend the
      die_find_variable_by_reg() to handle the following expressions
      
       * DW_OP_breg{0..31}
       * DW_OP_bregx
       * DW_OP_fbreg
      
      Ususally DWARF subprogram entries have frame base information and
      use it to locate stack variable like below:
      
       <2><43d1575>: Abbrev Number: 62 (DW_TAG_variable)
          <43d1576>   DW_AT_location    : 2 byte block: 91 7c         (DW_OP_fbreg: -4)  <--- here
          <43d1579>   DW_AT_name        : (indirect string, offset: 0x2c00c9): i
          <43d157d>   DW_AT_decl_file   : 1
          <43d157e>   DW_AT_decl_line   : 78
          <43d157f>   DW_AT_type        : <0x43d19d7>
      
      I found some differences on saving the frame base between gcc and clang.
      The gcc uses the CFA to get the base so it needs to check the current
      frame's CFI info.  In this case, stack offset needs to be adjusted from
      the start of the CFA.
      
       <1><1bb8d>: Abbrev Number: 102 (DW_TAG_subprogram)
          <1bb8e>   DW_AT_name        : (indirect string, offset: 0x74d41): kernel_init
          <1bb92>   DW_AT_decl_file   : 2
          <1bb92>   DW_AT_decl_line   : 1440
          <1bb94>   DW_AT_decl_column : 18
          <1bb95>   DW_AT_prototyped  : 1
          <1bb95>   DW_AT_type        : <0xcc>
          <1bb99>   DW_AT_low_pc      : 0xffffffff81bab9e0
          <1bba1>   DW_AT_high_pc     : 0x1b2
          <1bba9>   DW_AT_frame_base  : 1 byte block: 9c      (DW_OP_call_frame_cfa)  <------ here
          <1bbab>   DW_AT_call_all_calls: 1
          <1bbab>   DW_AT_sibling     : <0x1bf5a>
      
      While clang sets it to a register directly and it can check the register
      and offset in the instruction directly.
      
       <1><43d1542>: Abbrev Number: 60 (DW_TAG_subprogram)
          <43d1543>   DW_AT_low_pc      : 0xffffffff816a7c60
          <43d154b>   DW_AT_high_pc     : 0x98
          <43d154f>   DW_AT_frame_base  : 1 byte block: 56    (DW_OP_reg6 (rbp))  <---------- here
          <43d1551>   DW_AT_GNU_all_call_sites: 1
          <43d1551>   DW_AT_name        : (indirect string, offset: 0x3bce91): foo
          <43d1555>   DW_AT_decl_file   : 1
          <43d1556>   DW_AT_decl_line   : 75
          <43d1557>   DW_AT_prototyped  : 1
          <43d1557>   DW_AT_type        : <0x43c7332>
          <43d155b>   DW_AT_external    : 1
      
      Also it needs to update the offset after finding the type like global
      variables since the offset was from the frame base.  Factor out
      match_var_offset() to check global and local variables in the same way.
      
      The type stats are improved too:
      
        Annotate data type stats:
        total 294, ok 160 (54.4%), bad 134 (45.6%)
        -----------------------------------------------------------
                30 : no_sym
                32 : no_mem_ops
                51 : no_var
                14 : no_typeinfo
                 7 : bad_offset
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Link: https://lore.kernel.org/r/20240117062657.985479-9-namhyung@kernel.orgSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      bc10db8e