From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Ravi Bangoria <ravi.bangoria@amd.com>,
kajoljain <kjain@linux.ibm.com>,
peterz@infradead.org, acme@kernel.org
Cc: jolsa@kernel.org, namhyung@kernel.org, eranian@google.com,
irogers@google.com, jmario@redhat.com, leo.yan@linaro.org,
alisaidi@amazon.com, ak@linux.intel.com,
dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
tglx@linutronix.de, bp@alien8.de, x86@kernel.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
sandipan.das@amd.com, ananth.narayan@amd.com,
kim.phillips@amd.com, santosh.shukla@amd.com
Subject: Re: [PATCH v3 01/15] perf/mem: Introduce PERF_MEM_LVLNUM_{EXTN_MEM|IO}
Date: Fri, 30 Sep 2022 10:17:32 -0400 [thread overview]
Message-ID: <88c920de-5af6-c7b0-d6a8-6c365491dd3e@linux.intel.com> (raw)
In-Reply-To: <a36ffee0-b0d5-5941-8d98-cc8e9b100a50@amd.com>
On 2022-09-30 8:50 a.m., Ravi Bangoria wrote:
> On 30-Sep-22 4:18 PM, kajoljain wrote:
>>
>>
>> On 9/28/22 15:27, Ravi Bangoria wrote:
>>> PERF_MEM_LVLNUM_EXTN_MEM which can be used to indicate accesses to
>>> extension memory like CXL etc. PERF_MEM_LVL_IO can be used for IO
>>> accesses but it can not distinguish between local and remote IO.
>>> Introduce new field PERF_MEM_LVLNUM_IO which can be clubbed with
>>> PERF_MEM_REMOTE_REMOTE to indicate Remote IO accesses.
>>>
>>> Signed-off-by: Ravi Bangoria <ravi.bangoria@amd.com>
>>> ---
>>> include/uapi/linux/perf_event.h | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
>>> index e639c74cf5fb..4ae3c249f675 100644
>>> --- a/include/uapi/linux/perf_event.h
>>> +++ b/include/uapi/linux/perf_event.h
>>> @@ -1336,7 +1336,9 @@ union perf_mem_data_src {
>>> #define PERF_MEM_LVLNUM_L2 0x02 /* L2 */
>>> #define PERF_MEM_LVLNUM_L3 0x03 /* L3 */
>>> #define PERF_MEM_LVLNUM_L4 0x04 /* L4 */
>>> -/* 5-0xa available */
>>> +/* 5-0x8 available */
>>> +#define PERF_MEM_LVLNUM_EXTN_MEM 0x09 /* Extension memory */
>>
>> Hi Ravi,
>> Here we are adding entry explicitly for accesses to Extension memory
>> like CXL. In future if we want to extend it for cache or other accesses
>> , we again need to add new entries.
>> Can we rather add single entry say PERF_MEM_LVLNUM_EXTN and further can
>> use reserved bits to specify memory/cache?
>
> Is everybody okay with this:
>
> #define PERF_MEM_LVLNUM_EXTN 0x09 /* CXL */
I think a generic name, PERF_MEM_LVLNUM_EXTN, only make sense, when it
wants to include all the types of the Extension memory, e.g., CXL, PMEM,
HBM, etc. Then we can set this bit and the corresponding CXL bits to
understand the real source. Is it the case here?
But if it's only for the CXL, I think it's better to use a dedicated
name, PERF_MEM_LVLNUM_CXL. (as we did for PMEM, PERF_MEM_LVLNUM_PMEM).
If so, I don't think we need the PERF_MEM_EXTN_CXL_ANY.
Thanks,
Kan
>
> And a 3 bit variable to define what type of cxl that would be:
>
> #define PERF_MEM_EXTN_CXL_ANY 0x1
> #define PERF_MEM_EXTN_CXL_MEM 0x2
> #define PERF_MEM_EXTN_CXL_CACHE 0x2
> #define PERF_MEM_EXTN_CXL_IO 0x3
>
> Peter, Shall I send this as addon patch series or are you okay reverting
> current patches?
>
> Thanks,
> Ravi
next prev parent reply other threads:[~2022-09-30 14:17 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-28 9:57 [PATCH v3 00/15] perf mem/c2c: Add support for AMD Ravi Bangoria
2022-09-28 9:57 ` [PATCH v3 01/15] perf/mem: Introduce PERF_MEM_LVLNUM_{EXTN_MEM|IO} Ravi Bangoria
2022-09-30 10:48 ` kajoljain
2022-09-30 12:50 ` Ravi Bangoria
2022-09-30 14:17 ` Liang, Kan [this message]
2022-10-01 6:37 ` Ravi Bangoria
2022-10-03 13:15 ` Liang, Kan
2022-10-06 11:38 ` Ravi Bangoria
2022-10-14 13:53 ` Arnaldo Carvalho de Melo
2022-10-14 15:04 ` Ravi Bangoria
2022-10-27 8:25 ` Peter Zijlstra
2022-09-28 9:57 ` [PATCH v3 02/15] perf/x86/amd: Add IBS OP_DATA2 DataSrc bit definitions Ravi Bangoria
2022-09-30 4:41 ` Namhyung Kim
2022-09-30 4:48 ` Ravi Bangoria
2022-09-30 5:11 ` Namhyung Kim
2022-09-30 6:16 ` Ravi Bangoria
2022-09-28 9:57 ` [PATCH v3 03/15] perf/x86/amd: Support PERF_SAMPLE_DATA_SRC Ravi Bangoria
2022-09-28 9:57 ` [PATCH v3 04/15] perf/x86/amd: Support PERF_SAMPLE_{WEIGHT|WEIGHT_STRUCT} Ravi Bangoria
2022-09-30 5:09 ` Namhyung Kim
2022-09-28 9:57 ` [PATCH v3 05/15] perf/x86/amd: Support PERF_SAMPLE_ADDR Ravi Bangoria
2022-09-28 9:57 ` [PATCH v3 06/15] perf/x86/amd: Support PERF_SAMPLE_PHY_ADDR Ravi Bangoria
2022-09-30 4:59 ` Namhyung Kim
2022-09-30 5:05 ` Ravi Bangoria
2022-09-30 17:02 ` Jiri Olsa
2022-09-28 9:57 ` [PATCH v3 07/15] perf/uapi: Define PERF_MEM_SNOOPX_PEER in kernel header file Ravi Bangoria
2022-09-28 9:57 ` [PATCH v3 08/15] perf tool: Sync include/uapi/linux/perf_event.h header Ravi Bangoria
2022-09-28 9:57 ` [PATCH v3 09/15] perf tool: Sync arch/x86/include/asm/amd-ibs.h header Ravi Bangoria
2022-09-28 9:58 ` [PATCH v3 10/15] perf mem: Add support for printing PERF_MEM_LVLNUM_{EXTN_MEM|IO} Ravi Bangoria
2022-09-28 9:58 ` [PATCH v3 11/15] perf mem/c2c: Set PERF_SAMPLE_WEIGHT for LOAD_STORE events Ravi Bangoria
2022-09-28 9:58 ` [PATCH v3 12/15] perf mem/c2c: Add load store event mappings for AMD Ravi Bangoria
2022-09-28 9:58 ` [PATCH v3 13/15] perf mem/c2c: Avoid printing empty lines for unsupported events Ravi Bangoria
2022-09-28 9:58 ` [PATCH v3 14/15] perf mem: Use more generic term for LFB Ravi Bangoria
2022-09-28 9:58 ` [PATCH v3 15/15] perf script: Add missing fields in usage hint 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=88c920de-5af6-c7b0-d6a8-6c365491dd3e@linux.intel.com \
--to=kan.liang@linux.intel.com \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=alisaidi@amazon.com \
--cc=ananth.narayan@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jmario@redhat.com \
--cc=jolsa@kernel.org \
--cc=kim.phillips@amd.com \
--cc=kjain@linux.ibm.com \
--cc=leo.yan@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@amd.com \
--cc=sandipan.das@amd.com \
--cc=santosh.shukla@amd.com \
--cc=tglx@linutronix.de \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).