All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ravi Bangoria <ravi.bangoria@amd.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: peterz@infradead.org, mingo@kernel.org, acme@kernel.org,
	eranian@google.com, kan.liang@linux.intel.com, jolsa@kernel.org,
	irogers@google.com, linux-perf-users@vger.kernel.org,
	linux-kernel@vger.kernel.org, sandipan.das@amd.com,
	ananth.narayan@amd.com, santosh.shukla@amd.com,
	Ravi Bangoria <ravi.bangoria@amd.com>
Subject: Re: [PATCH v2] perf/x86/ibs: Set mem_lvl_num, mem_remote and mem_hops for data_src
Date: Wed, 29 Mar 2023 15:15:23 +0530	[thread overview]
Message-ID: <00f1954f-cf55-d954-5dc6-0da95f8ea308@amd.com> (raw)
In-Reply-To: <CAM9d7ciQLXAcVwFJWeJDHwkwUQ-rnHvdetYsQn7w83kkOsFKWg@mail.gmail.com>

Hi Namhyung,

>> @@ -716,25 +748,19 @@ static void perf_ibs_get_mem_lvl(union ibs_op_data2 *op_data2,
>>          * DcMiss, L2Miss, DataSrc, DcMissLat etc. are all invalid for Uncached
>>          * memory accesses. So, check DcUcMemAcc bit early.
>>          */
>> -       if (op_data3->dc_uc_mem_acc && ibs_data_src != IBS_DATA_SRC_EXT_IO) {
>> -               data_src->mem_lvl = PERF_MEM_LVL_UNC | PERF_MEM_LVL_HIT;
>> -               return;
>> -       }
>> +       if (op_data3->dc_uc_mem_acc && ibs_data_src != IBS_DATA_SRC_EXT_IO)
>> +               return L(UNC);
> 
> Hmm.. it seems we don't have PERF_MEM_LVLNUM_UNC.

Right. Is it worth to introduce one?

On a side note, I came to know that IBS OpData2[RmtNode] is not applicable
when DataSrc=7 (I/O). So, I need to respin this patch with that change.

[...]

>>  check_mab:
>> @@ -830,12 +810,11 @@ static void perf_ibs_get_mem_lvl(union ibs_op_data2 *op_data2,
>>          * DataSrc simultaneously. Prioritize DataSrc over MAB, i.e. set
>>          * MAB only when IBS fails to provide DataSrc.
>>          */
>> -       if (op_data3->dc_miss_no_mab_alloc) {
>> -               data_src->mem_lvl = PERF_MEM_LVL_LFB | PERF_MEM_LVL_HIT;
>> -               return;
>> -       }
>> +       if (op_data3->dc_miss_no_mab_alloc)
>> +               return L(LFB) | LN(LFB);
>>
>>         data_src->mem_lvl = PERF_MEM_LVL_NA;
>> +       return 0;
> 
> Wouldn't it be 'return L(NA) | LN(NA);' ?

IBS has no instruction type filtering, i.e. it tags whatever instruction it
sees at overflow. When IBS tags non-load/store instruction, data_src->val is
set to PERF_MEM_NA, which does not initialize mem_lvl_num (Shall we change
that?). If I set both LVL_NA and LVL_NUM_NA for load/store with no DataSrc
info, perf mem output becomes funny:

  $ sudo ./perf mem report -F sample,mem --stdio
  #      Samples  Memory access
  # ............  .......................................
  #
            1914  N/A                   <====== Non-LS
             905  L1 or L1 hit
              19  L3 or L3 hit
              16  L2 or L2 hit
               6  N/A or N/A hit        <====== LS with no DataSrc info
               6  Local RAM or RAM hit
               4  Remote node, same socket RAM hit
               3  Remote core, same node Any cache hit
               2  Remote node, same socket Any cache hit

Also, L(NA) is PERF_MEM_LVL_NA | PERF_MEM_LVL_HIT. If I just return L(NA),
perf tools shows it as "N/A hit".

So, until tool code gets refactored, setting mem_lvl = NA here is hiding
tool's dumbness :(. Maybe I should refactor perf_mem__snp_scnprintf() as
part of this patchset.

Thanks,
Ravi

  reply	other threads:[~2023-03-29  9:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 13:08 [PATCH v2] perf/x86/ibs: Set mem_lvl_num, mem_remote and mem_hops for data_src Ravi Bangoria
2023-03-29  7:05 ` Namhyung Kim
2023-03-29  9:45   ` Ravi Bangoria [this message]
2023-03-29 23:47     ` Namhyung Kim
2023-03-30  4:38       ` Ravi Bangoria

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=00f1954f-cf55-d954-5dc6-0da95f8ea308@amd.com \
    --to=ravi.bangoria@amd.com \
    --cc=acme@kernel.org \
    --cc=ananth.narayan@amd.com \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sandipan.das@amd.com \
    --cc=santosh.shukla@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.