Date: Wed, 26 Jun 2024 14:55:09 -0400
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: Ian Rogers <irogers@...gle.com>
Cc: peterz@...radead.org, mingo@...nel.org, acme@...nel.org,
 namhyung@...nel.org, adrian.hunter@...el.com,
 alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org,
 ak@...ux.intel.com, eranian@...gle.com
Subject: Re: [PATCH V2 00/13] Support Lunar Lake and Arrow Lake core PMU



On 2024-06-26 1:22 p.m., Ian Rogers wrote:
> On Wed, Jun 26, 2024 at 6:11 AM Liang, Kan <kan.liang@...ux.intel.com> wrote:
>>
>>
>>
>> On 2024-06-26 1:20 a.m., Ian Rogers wrote:
>>> On Tue, Jun 25, 2024 at 11:22 AM <kan.liang@...ux.intel.com> wrote:
>>>>
>>>> From: Kan Liang <kan.liang@...ux.intel.com>
>>>>
>>>> Changes since V1:
>>>> - Add x86/intel_pmu_max_num_pebs/counters/counters_fixed()
>>>> - Rename model-specific pebs_latency_data functions
>>>> - Rename V6 counter MSRs
>>>>
>>>> From the core PMU' perspective, the Lunar Lake and Arrow Lake are the
>>>> same, which are similar to the previous generation Meteor Lake. Both are
>>>> hybrid platforms, with e-core and p-core.
>>>>
>>>> The key differences include:
>>>> - The e-core supports 3 new fixed counters
>>>> - The p-core supports an updated PEBS Data Source format
>>>> - More GP counters (Updated event constraint table)
>>>> - New Architectural performance monitoring V6
>>>>   (New Perfmon MSRs aliasing, umask2, eq).
>>>> - New PEBS format V6 (Counters Snapshotting group)
>>>> - New RDPMC metrics clear mode
>>>>
>>>> The details for the above new features can be found in the Intel
>>>> Architecture Instruction Set Extensions and Future Features (052).
>>>> https://cdrdv2.intel.com/v1/dl/getContent/671368
>>>>
>>>> The counters may not be continuous anymore. Patch 1-2 converts the max
>>>> number of counters to a mask of counters. The change is a generic change
>>>> which impacts all X86 platforms.
>>>>
>>>> Patch 3-4 supports all the legacy features on LNL and ARL.
>>>>
>>>> Patch 5-7 supports the new Architectural performance monitoring V6.
>>>>
>>>> Patch 8-11 supports the new PEBS format V6.
>>>>
>>>> Patch 12 supports the new RDPMC metrics clear mode.
>>>>
>>>> Kan Liang (13):
>>>>   perf/x86/intel: Support the PEBS event mask
>>>>   perf/x86: Support counter mask
>>>>   perf/x86: Add Lunar Lake and Arrow Lake support
>>>>   perf/x86/intel: Rename model-specific pebs_latency_data functions
>>>>   perf/x86/intel: Support new data source for Lunar Lake
>>>>   perf/x86: Add config_mask to represent EVENTSEL bitmask
>>>>   perf/x86/intel: Support PERFEVTSEL extension
>>>>   perf/x86/intel: Support Perfmon MSRs aliasing
>>>>   perf/x86: Extend event update interface
>>>>   perf: Extend perf_output_read
>>>>   perf/x86/intel: Move PEBS event update after the sample output
>>>>   perf/x86/intel: Support PEBS counters snapshotting
>>>>   perf/x86/intel: Support RDPMC metrics clear mode
>>>
>>> Fwiw and beside the nit:
>>>
>>> Reviewed-by: Ian Rogers <irogers@...gle.com>
>>
>> Thanks!
>>
>>>
>>> It seems some of the behaviors could have tests upon them, would it be
>>> possible to add them skipping the test on older and non-Intel
>>> architectures?
>>
>> I think only the two features (Architectural performance monitoring V6
>> and the RDPMC metrics clear mode) add new formats, which impacts the ABI.
>>
>> The perf tool has a "Sysfs PMU tests" case to verify the event format.
>> It creates a fake sysfs mount to verify all the possible format
>> definitions, rather than the real format on a given machine.
>>
>> I think the test case make sense, since it's impossible to test all the
>> formats. As long as all the possible combinations of the format
>> definition are supported, the perf tool should be good.
>>
>> The umask becomes non-contiguous in V6. There is already a case in the
>> "Sysfs PMU tests" to cover such format definition.
>> The current perf test should be good enough to cover the ABI changes.
>>
>> 9: Sysfs PMU tests                                                 :
>> 9.1: Parsing with PMU format directory                             : Ok
>> 9.2: Parsing with PMU event                                        : Ok
>> 9.3: PMU event names                                               : Ok
>> 9.4: PMU name combining                                            : Ok
>> 9.5: PMU name comparison                                           : Ok
> 
> That's good. I was thinking more about leader sampling testing. We
> have an attribute test and an event parsing test, but nothing that
> currently tests leader sampling actually works even if it is just a
> coverage test. 

Yes, the sampling read test is missed.

> We could do something like this:
> 
> ```
> diff --git a/tools/perf/tests/shell/record.sh b/tools/perf/tests/shell/record.sh
> index 3d1a7759a7b2..9b61e2d01c9e 100755
> --- a/tools/perf/tests/shell/record.sh
> +++ b/tools/perf/tests/shell/record.sh
> @@ -190,11 +190,29 @@ test_branch_counter() {
>   echo "Basic branch counter test [Success]"
> }
> 
> +test_leader_sampling() {
> +  echo "Basic leader sampling test"
> +  if ! perf record -o "${perfdata}" -g -e
> "{instructions,branch-misses}:S" ${testprog} 2> /dev/null
> +  then
> +    echo "Leader sampling [Failed record]"
> +    err=1
> +    return
> +  fi
> +  if ! perf script -D -i "${perfdata}" | grep -q "sample_read:"
> +  then
> +    echo "Leader sampling [Failed missing output]"
> +    err=1
> +    return
> +  fi
> +  echo "Basic leader sampling test [Success]"
> +}
> +
> test_per_thread
> test_register_capture
> test_system_wide
> test_workload
> test_branch_counter
> +test_leader_sampling
> 
> cleanup
> exit $err
> ```
> 
> But it'd be nice if we had coverage of things like fixed counters vs
> generic, the improvements now fixed in LNL, etc.

The improvements in LNL should be transparent for the perf tool. It just
changes the places where to read the counter (from "directly read the HW
counter" to "read it in a PEBS record"). It is hard to design a perf
tool test case to verify the small difference.

But, I guess we can choose proper events to test the fixed counters vs
generic.

Also, there are some special cases for the sampling read. For example,
the AUX area event and the Topdown slots event cannot be sampled. If
they are the leader, the next event will be the sampling event.
We may also design a case to cover it as well.

I will think about it and send a separate patch to cover the sampling read.

Thanks,
Kan

> 
> Thanks,
> Ian
> 
>> Thanks,
>> Kan
>>>
>>> Thanks,
>>> Ian
>>>
>>>>  arch/x86/events/amd/core.c           |  26 +-
>>>>  arch/x86/events/core.c               | 123 +++----
>>>>  arch/x86/events/intel/core.c         | 471 ++++++++++++++++++++-------
>>>>  arch/x86/events/intel/ds.c           | 288 +++++++++++++---
>>>>  arch/x86/events/intel/knc.c          |   2 +-
>>>>  arch/x86/events/intel/p4.c           |  12 +-
>>>>  arch/x86/events/intel/p6.c           |   2 +-
>>>>  arch/x86/events/perf_event.h         | 105 +++++-
>>>>  arch/x86/events/perf_event_flags.h   |   2 +-
>>>>  arch/x86/events/zhaoxin/core.c       |  14 +-
>>>>  arch/x86/include/asm/intel_ds.h      |   1 +
>>>>  arch/x86/include/asm/msr-index.h     |   6 +
>>>>  arch/x86/include/asm/perf_event.h    |  27 ++
>>>>  include/uapi/linux/perf_event.h      |   6 +-
>>>>  kernel/events/core.c                 |  15 +-
>>>>  tools/perf/Documentation/topdown.txt |   9 +-
>>>>  16 files changed, 839 insertions(+), 270 deletions(-)
>>>>
>>>> --
>>>> 2.35.1
>>>>
>>>

Powered by blists - more mailing lists