mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ilkka Koskinen <ilkka@os.amperecomputing.com>
To: Leo Yan <leo.yan@arm.com>
Cc: Ilkka Koskinen <ilkka@os.amperecomputing.com>,
	 Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	 Arnaldo Carvalho de Melo <acme@kernel.org>,
	 Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	 Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	 Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	 Adrian Hunter <adrian.hunter@intel.com>,
	 "Liang, Kan" <kan.liang@linux.intel.com>,
	 John Garry <john.g.garry@oracle.com>,
	Will Deacon <will@kernel.org>,
	 James Clark <james.clark@linaro.org>,
	Mike Leach <mike.leach@linaro.org>,  Leo Yan <leo.yan@linux.dev>,
	linux-perf-users@vger.kernel.org,  linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] perf arm-spe: Add support for SPE Data Source packet on AmpereOne
Date: Mon, 28 Oct 2024 19:28:19 -0700 (PDT)	[thread overview]
Message-ID: <5929238-399a-b4d-3b8a-2f5b8b7a473@os.amperecomputing.com> (raw)
In-Reply-To: <20241025144303.GC359792@e132581.arm.com>


Hi Leo,

On Fri, 25 Oct 2024, Leo Yan wrote:
> On Thu, Oct 24, 2024 at 11:30:35PM +0000, Ilkka Koskinen wrote:
>>
>> Decode SPE Data Source packets on AmpereOne. The field is IMPDEF.
>>
>> Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
>> ---
>>  .../util/arm-spe-decoder/arm-spe-decoder.h    |  9 +++
>>  tools/perf/util/arm-spe.c                     | 61 +++++++++++++++++++
>>  2 files changed, 70 insertions(+)
>>
>> diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
>> index 1443c28545a9..e4115b1e92b2 100644
>> --- a/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
>> +++ b/tools/perf/util/arm-spe-decoder/arm-spe-decoder.h
>> @@ -67,6 +67,15 @@ enum arm_spe_neoverse_data_source {
>>         ARM_SPE_NV_DRAM          = 0xe,
>>  };
>>
>> +enum arm_spe_ampereone_data_source {
>> +       ARM_SPE_AMPEREONE_LOCAL_CHIP_CACHE_OR_DEVICE    = 0x0,
>> +       ARM_SPE_AMPEREONE_SLC                           = 0x3,
>> +       ARM_SPE_AMPEREONE_REMOTE_CHIP_CACHE             = 0x5,
>> +       ARM_SPE_AMPEREONE_DDR                           = 0x7,
>> +       ARM_SPE_AMPEREONE_L1D                           = 0x8,
>> +       ARM_SPE_AMPEREONE_L2D                           = 0x9,
>> +};
>> +
>>  struct arm_spe_record {
>>         enum arm_spe_sample_type type;
>>         int err;
>> diff --git a/tools/perf/util/arm-spe.c b/tools/perf/util/arm-spe.c
>> index 138ffc71b32d..04bd21ad7ea8 100644
>> --- a/tools/perf/util/arm-spe.c
>> +++ b/tools/perf/util/arm-spe.c
>> @@ -515,10 +515,69 @@ static void arm_spe__synth_data_source_generic(const struct arm_spe_record *reco
>>                 data_src->mem_lvl |= PERF_MEM_LVL_REM_CCE1;
>>  }
>>
>> +static const struct midr_range ampereone_source_spe[] = {
>> +       MIDR_ALL_VERSIONS(MIDR_AMPERE1A),
>> +       {},
>> +};
>> +
>> +static void arm_spe__synth_data_source_ampereone(const struct arm_spe_record *record,
>> +                                                union perf_mem_data_src *data_src,
>> +                                                u64 midr)
>> +{
>> +       if (!is_midr_in_range_list(midr, ampereone_source_spe)) {
>> +               arm_spe__synth_data_source_generic(record, data_src);
>> +               return;
>> +       }
>
> With James' suggestion, I don't think here need to check the CPU
> variant again.  All generic data source generating should run in the
> arm_spe__synth_data_source() function.

Yep, checking the implementor ID was just wrong and unnecessary.
I fix that.

>
>> +
>> +       if (record->op & ARM_SPE_OP_ST) {
>> +               data_src->mem_lvl = PERF_MEM_LVL_NA;
>> +               data_src->mem_lvl_num = PERF_MEM_LVLNUM_NA;
>> +               data_src->mem_snoop = PERF_MEM_SNOOP_NA;
>> +               return;
>> +       }
>> +
>> +       switch (record->source) {
>> +       case ARM_SPE_AMPEREONE_LOCAL_CHIP_CACHE_OR_DEVICE:
>> +               data_src->mem_lvl = PERF_MEM_LVL_L2 | PERF_MEM_LVL_HIT;
>> +               data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2;
>> +               data_src->mem_snoopx = PERF_MEM_SNOOPX_PEER;
>> +               break;
>> +       case ARM_SPE_AMPEREONE_SLC:
>> +               data_src->mem_lvl = PERF_MEM_LVL_L3 | PERF_MEM_LVL_HIT;
>> +               data_src->mem_lvl_num = PERF_MEM_LVLNUM_L3;
>> +               data_src->mem_snoop = PERF_MEM_SNOOP_HIT;
>> +               break;
>> +       case ARM_SPE_AMPEREONE_REMOTE_CHIP_CACHE:
>> +               data_src->mem_lvl = PERF_MEM_LVL_REM_CCE1;
>> +               data_src->mem_lvl_num = PERF_MEM_LVLNUM_ANY_CACHE;
>> +               data_src->mem_remote = PERF_MEM_REMOTE_REMOTE;
>> +               data_src->mem_snoopx = PERF_MEM_SNOOPX_PEER;
>> +               break;
>> +       case ARM_SPE_AMPEREONE_DDR:
>> +               data_src->mem_lvl = PERF_MEM_LVL_LOC_RAM | PERF_MEM_LVL_HIT;
>> +               data_src->mem_lvl_num = PERF_MEM_LVLNUM_RAM;
>> +               data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
>> +               break;
>> +       case ARM_SPE_AMPEREONE_L1D:
>> +               data_src->mem_lvl = PERF_MEM_LVL_L1 | PERF_MEM_LVL_HIT;
>> +               data_src->mem_lvl_num = PERF_MEM_LVLNUM_L1;
>> +               data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
>> +               break;
>> +       case ARM_SPE_AMPEREONE_L2D:
>> +               data_src->mem_lvl = PERF_MEM_LVL_L2 | PERF_MEM_LVL_HIT;
>> +               data_src->mem_lvl_num = PERF_MEM_LVLNUM_L2;
>> +               data_src->mem_snoop = PERF_MEM_SNOOP_NONE;
>> +               break;
>
> We have another way to do this.  If convert the SoC specific data source
> to common data source values, e.g.
>
>  ARM_SPE_AMPEREONE_LOCAL_CHIP_CACHE_OR_DEVICE -> ARM_SPE_NV_PEER_CORE
>  ARM_SPE_AMPEREONE_SLC -> ARM_SPE_NV_SYS_CACHE
>  ARM_SPE_AMPEREONE_REMOTE_CHIP_CACHE -> ARM_SPE_NV_REMOTE
>  ARM_SPE_AMPEREONE_DDR -> ARM_SPE_NV_DRAM
>  ...
>
> Then we don't need to maintain two functions with almost same setting.
>
> I have no strong opinion for this. A dedicated function for Ampere CPU
> might give a bit flexiblity for later tweaking. It is up to you.

Let me think about it and see how it would look like.

>
> Last thing, please work on the the latest perf-tools-next branch:
>
>  https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git
>  branch: perf-tools-next
>
> Recently we have Arm SPE data source refactoring, please rebase on it.

Uh, for some reason I rebased it on top of Will's arm64 tree. Sorry about 
that.

Cheers, Ilkka

>
> Thanks,
> Leo
>
>> +       default:
>> +               break;
>> +       }
>> +}
>> +
>>  static u64 arm_spe__synth_data_source(const struct arm_spe_record *record, u64 midr)
>>  {
>>         union perf_mem_data_src data_src = { .mem_op = PERF_MEM_OP_NA };
>>         bool is_neoverse = is_midr_in_range_list(midr, neoverse_spe);
>> +       bool is_ampereone = (read_cpuid_implementor() == ARM_CPU_IMP_AMPERE);
>>
>>         if (record->op & ARM_SPE_OP_LD)
>>                 data_src.mem_op = PERF_MEM_OP_LOAD;
>> @@ -529,6 +588,8 @@ static u64 arm_spe__synth_data_source(const struct arm_spe_record *record, u64 m
>>
>>         if (is_neoverse)
>>                 arm_spe__synth_data_source_neoverse(record, &data_src);
>> +       else if (is_ampereone)
>> +               arm_spe__synth_data_source_ampereone(record, &data_src, midr);
>>         else
>>                 arm_spe__synth_data_source_generic(record, &data_src);
>>
>> --
>> 2.47.0
>>
>>
>

      reply	other threads:[~2024-10-29  2:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-24 23:30 Ilkka Koskinen
2024-10-25  8:35 ` James Clark
2024-10-29  2:06   ` Ilkka Koskinen
2024-10-25 14:43 ` Leo Yan
2024-10-29  2:28   ` Ilkka Koskinen [this message]

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=5929238-399a-b4d-3b8a-2f5b8b7a473@os.amperecomputing.com \
    --to=ilkka@os.amperecomputing.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@linaro.org \
    --cc=john.g.garry@oracle.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=leo.yan@arm.com \
    --cc=leo.yan@linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    /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

all inboxes | Powered by JetHome®