linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: irogers@google.com, maddy@linux.ibm.com, kjain@linux.ibm.com,
	adrian.hunter@intel.com, acme@kernel.org,
	linux-perf-users@vger.kernel.org, jolsa@kernel.org,
	disgoel@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 0/3] Add data type profiling support for powerpc
Date: Mon, 1 Apr 2024 14:57:39 -0700	[thread overview]
Message-ID: <CAM9d7chQBpqipotQwc_ASYhzi9ZOP+TfenBzFJjyQ3-j5kGRBg@mail.gmail.com> (raw)
In-Reply-To: <20240309072513.9418-1-atrajeev@linux.vnet.ibm.com>

Hello,

Sorry for the super late reply.


On Fri, Mar 8, 2024 at 11:25 PM Athira Rajeev
<atrajeev@linux.vnet.ibm.com> wrote:
>
> The patchset from Namhyung added support for data type profiling
> in perf tool. This enabled support to associate PMU samples to data
> types they refer using DWARF debug information. With the upstream
> perf, currently it possible to run perf report or perf annotate to
> view the data type information on x86.
>
> This patchset includes changes need to enable data type profiling
> support for powerpc. Main change are:
> 1. powerpc instruction nmemonic table to associate load/store
> instructions with move_ops which is use to identify if instruction
> is a memory access one.
> 2. To get register number and access offset from the given
> instruction, code uses fields from "struct arch" -> objump.
> Add entry for powerpc here.
> 3. A get_arch_regnum to return register number from the
> register name string.
>
> These three patches are the basic foundational patches.
> With these changes, data types is getting identified for kernel
> and user-space samples. There are still samples, which comes as
> "unknown" and needs to be checked. We plan to get those addressed
> in follow up. With the current patchset:
>
>  ./perf record -a -e mem-loads sleep 1
>  ./perf report -s type,typeoff --hierarchy --group --stdio
> Snippet of logs:
>
>  Total Lost Samples: 0
>
>  Samples: 277  of events 'mem-loads, dummy:u'
>  Event count (approx.): 149813
>
>             Overhead  Data Type / Data Type Offset
>  ...................  ............................
>
>     65.93%   0.00%     (unknown)
>        65.93%   0.00%     (unknown) +0 (no field)
>      8.19%   0.00%     struct vm_area_struct
>         8.19%   0.00%     struct vm_area_struct +136 (vm_file)
>      4.53%   0.00%     struct rq
>         3.14%   0.00%     struct rq +0 (__lock.raw_lock.val)
>         0.83%   0.00%     struct rq +3216 (avg_irq.runnable_sum)
>         0.24%   0.00%     struct rq +4 (nr_running)
>         0.14%   0.00%     struct rq +12 (nr_preferred_running)
>         0.12%   0.00%     struct rq +2760 (sd)
>         0.06%   0.00%     struct rq +3368 (prev_steal_time_rq)
>         0.01%   0.00%     struct rq +2592 (curr)
>      3.53%   0.00%     struct rb_node
>         3.53%   0.00%     struct rb_node +0 (__rb_parent_color)
>      3.43%   0.00%     struct slab
>         3.43%   0.00%     struct slab +32 (freelist)
>      3.30%   0.00%     unsigned int
>         3.30%   0.00%     unsigned int +0 (no field)
>      3.22%   0.00%     struct vm_fault
>         3.22%   0.00%     struct vm_fault +48 (pmd)
>      2.55%   0.00%     unsigned char
>         2.55%   0.00%     unsigned char +0 (no field)
>      1.06%   0.00%     struct task_struct
>         1.06%   0.00%     struct task_struct +4 (thread_info.cpu)
>      0.92%   0.00%     void*
>         0.92%   0.00%     void* +0 (no field)
>      0.74%   0.00%     __int128 unsigned
>         0.74%   0.00%     __int128 unsigned +8 (no field)
>      0.59%   0.00%     struct perf_event
>         0.54%   0.00%     struct perf_event +552 (ctx)
>         0.04%   0.00%     struct perf_event +152 (pmu)
>      0.20%   0.00%     struct sched_entity
>         0.20%   0.00%     struct sched_entity +0 (load.weight)
>      0.18%   0.00%     struct cfs_rq
>         0.18%   0.00%     struct cfs_rq +96 (curr)

Cool!  I'm happy to see it works well on powerpc too.

Lots of codes are still assuming x86 so you may need to
add separate logics like parsing the instruction location.

And instruction tracking is also a great concern.
But we may have something in the clang/LLVM to produce
more debug information and hopefully we can remove the
instruction tracking at all.

https://github.com/llvm/llvm-project/pull/81545

Anyway I'm really looking forward to seeing v2 soon.

Thanks,
Namhyung

>
> Athira Rajeev (3):
>   tools/perf/arch/powerpc: Add load/store in powerpc annotate
>     instructions for data type profling
>   tools/erf/util/annotate: Set register_char and memory_ref_char for
>     powerpc
>   tools/perf/arch/powerc: Add get_arch_regnum for powerpc
>
>  .../perf/arch/powerpc/annotate/instructions.c | 66 +++++++++++++++++++
>  tools/perf/arch/powerpc/util/dwarf-regs.c     | 29 ++++++++
>  tools/perf/util/annotate.c                    |  5 ++
>  3 files changed, 100 insertions(+)
>
> --
> 2.43.0
>

  parent reply	other threads:[~2024-04-01 21:58 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-09  7:25 [PATCH 0/3] Add data type profiling support for powerpc Athira Rajeev
2024-03-09  7:25 ` [PATCH 1/3] tools/perf/arch/powerpc: Add load/store in powerpc annotate instructions for data type profling Athira Rajeev
2024-03-09  9:48   ` Christophe Leroy
2024-03-18 11:01     ` Athira Rajeev
2024-03-09  7:25 ` [PATCH 2/3] tools/erf/util/annotate: Set register_char and memory_ref_char for powerpc Athira Rajeev
2024-03-09 17:43   ` Segher Boessenkool
2024-03-18 11:33     ` Athira Rajeev
2024-03-09  7:25 ` [PATCH 3/3] tools/perf/arch/powerc: Add get_arch_regnum " Athira Rajeev
2024-03-09  9:54   ` Christophe Leroy
2024-03-18 11:00     ` Athira Rajeev
2024-03-26  9:35   ` Tiezhu Yang
2024-04-01 21:46     ` Namhyung Kim
2024-04-01 21:57 ` Namhyung Kim [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-03-09  5:51 [PATCH 0/3] Add data type profiling support " Athira Rajeev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAM9d7chQBpqipotQwc_ASYhzi9ZOP+TfenBzFJjyQ3-j5kGRBg@mail.gmail.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=disgoel@linux.vnet.ibm.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kjain@linux.ibm.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).