[PATCH] KVM: selftests: Test top-down slots event

[PATCH] KVM: selftests: Test top-down slots event

[Dapeng Mi]

Although the fixed counter 3 and the exclusive pseudo slots events is
not supported by KVM yet, the architectural slots event is supported by
KVM and can be programed on any GP counter. Thus add validation for this
architectural slots event.

Top-down slots event "counts the total number of available slots for an
unhalted logical processor, and increments by machine-width of the
narrowest pipeline as employed by the Top-down Microarchitecture
Analysis method." So suppose the measured count of slots event would be
always larger than 0.

pmu_counters_test passed with this patch on Intel Sapphire Rapids.

Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
 tools/testing/selftests/kvm/x86_64/pmu_counters_test.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
index ae5f6042f1e8..99bcb619b861 100644
--- a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
+++ b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
@@ -117,6 +117,7 @@ static void guest_assert_event_count(uint8_t idx,
 		fallthrough;
 	case INTEL_ARCH_CPU_CYCLES_INDEX:
 	case INTEL_ARCH_REFERENCE_CYCLES_INDEX:
+	case INTEL_ARCH_TOPDOWN_SLOTS_INDEX:
 		GUEST_ASSERT_NE(count, 0);
 		break;
 	default:

base-commit: f0f3b810edda57f317d79f452056786257089667
-- 
2.40.1

Re: [PATCH] KVM: selftests: Test top-down slots event

[Sean Christopherson]

On Thu, Feb 01, 2024, Dapeng Mi wrote:
> Although the fixed counter 3 and the exclusive pseudo slots events is
> not supported by KVM yet, the architectural slots event is supported by
> KVM and can be programed on any GP counter. Thus add validation for this
> architectural slots event.
> 
> Top-down slots event "counts the total number of available slots for an
> unhalted logical processor, and increments by machine-width of the
> narrowest pipeline as employed by the Top-down Microarchitecture
> Analysis method." So suppose the measured count of slots event would be
> always larger than 0.

Please translate that into something non-perf folks can understand.  I know what
a pipeline slot is, and I know a dictionary's definition of "available" is, but I
still have no idea what this event actually counts.  In other words, I want a
precise definition of exactly what constitutes an "available slot", in verbiage
that anyone with basic understanding of x86 architectures can follow after reading
the whitepaper[*], which is helpful for understanding the concepts, but doesn't
crisply explain what this event counts.

Examples of when a slot is available vs. unavailable would be extremely helpful.

[*] https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2023-0/top-down-microarchitecture-analysis-method.html

Re: [PATCH] KVM: selftests: Test top-down slots event

[Mi, Dapeng]

On 2/2/2024 2:02 AM, Sean Christopherson wrote:
> On Thu, Feb 01, 2024, Dapeng Mi wrote:
>> Although the fixed counter 3 and the exclusive pseudo slots events is
>> not supported by KVM yet, the architectural slots event is supported by
>> KVM and can be programed on any GP counter. Thus add validation for this
>> architectural slots event.
>>
>> Top-down slots event "counts the total number of available slots for an
>> unhalted logical processor, and increments by machine-width of the
>> narrowest pipeline as employed by the Top-down Microarchitecture
>> Analysis method." So suppose the measured count of slots event would be
>> always larger than 0.
> Please translate that into something non-perf folks can understand.  I know what
> a pipeline slot is, and I know a dictionary's definition of "available" is, but I
> still have no idea what this event actually counts.  In other words, I want a
> precise definition of exactly what constitutes an "available slot", in verbiage
> that anyone with basic understanding of x86 architectures can follow after reading
> the whitepaper[*], which is helpful for understanding the concepts, but doesn't
> crisply explain what this event counts.
>
> Examples of when a slot is available vs. unavailable would be extremely helpful.
>
> [*] https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2023-0/top-down-microarchitecture-analysis-method.html

Yeah, indeed, 'slots' is not easily understood from its literal meaning. 
I also took some time to understand it when I look at this event for the 
first time. Simply speaking, slots is an abstract concept which 
indicates how many uops (decoded from instructions) can be processed 
simultaneously (per cycle) on HW. we assume there is a classic 5-stage 
pipeline, fetch, decode, execute, memory access and register writeback. 
In topdown micro-architectural analysis method, the former two stages 
(fetch/decode) is called front-end and the last three stages are called 
back-end.

In modern Intel processors, a complicated instruction could be decoded 
into several uops (micro-operations) and so these uops can be processed 
simultaneously and then improve the performance. Thus, assume a 
processor can decode and dispatch 4 uops in front-end and execute 4 uops 
in back-end simultaneously (per-cycle), so we would say this processor 
has 4 topdown slots per-cycle. If a slot is spare and can be used to 
process new uop, we say it's available, but if a slot is occupied by a 
uop for several cycles and not retired (maybe blocked by memory access), 
we say this slot is stall and unavailable.

Ok, I would rewrite the commit description and add more explanation there.

Re: [PATCH] KVM: selftests: Test top-down slots event

[Sean Christopherson]

On Fri, Feb 02, 2024, Dapeng Mi wrote:
> 
> On 2/2/2024 2:02 AM, Sean Christopherson wrote:
> > On Thu, Feb 01, 2024, Dapeng Mi wrote:
> > > Although the fixed counter 3 and the exclusive pseudo slots events is
> > > not supported by KVM yet, the architectural slots event is supported by
> > > KVM and can be programed on any GP counter. Thus add validation for this
> > > architectural slots event.
> > > 
> > > Top-down slots event "counts the total number of available slots for an
> > > unhalted logical processor, and increments by machine-width of the
> > > narrowest pipeline as employed by the Top-down Microarchitecture
> > > Analysis method." So suppose the measured count of slots event would be
> > > always larger than 0.
> > Please translate that into something non-perf folks can understand.  I know what
> > a pipeline slot is, and I know a dictionary's definition of "available" is, but I
> > still have no idea what this event actually counts.  In other words, I want a
> > precise definition of exactly what constitutes an "available slot", in verbiage
> > that anyone with basic understanding of x86 architectures can follow after reading
> > the whitepaper[*], which is helpful for understanding the concepts, but doesn't
> > crisply explain what this event counts.
> > 
> > Examples of when a slot is available vs. unavailable would be extremely helpful.
> > 
> > [*] https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2023-0/top-down-microarchitecture-analysis-method.html
> 
> Yeah, indeed, 'slots' is not easily understood from its literal meaning. I
> also took some time to understand it when I look at this event for the first
> time. Simply speaking, slots is an abstract concept which indicates how many
> uops (decoded from instructions) can be processed simultaneously (per cycle)
> on HW. we assume there is a classic 5-stage pipeline, fetch, decode,
> execute, memory access and register writeback. In topdown
> micro-architectural analysis method, the former two stages (fetch/decode) is
> called front-end and the last three stages are called back-end.
> 
> In modern Intel processors, a complicated instruction could be decoded into
> several uops (micro-operations) and so these uops can be processed
> simultaneously and then improve the performance. Thus, assume a processor
> can decode and dispatch 4 uops in front-end and execute 4 uops in back-end
> simultaneously (per-cycle), so we would say this processor has 4 topdown
> slots per-cycle. If a slot is spare and can be used to process new uop, we
> say it's available, but if a slot is occupied by a uop for several cycles
> and not retired (maybe blocked by memory access), we say this slot is stall
> and unavailable.

In that case, can't the test assert that the count is at least NUM_INSNS_RETIRED?
AFAIK, none of the sequences in the measured code can be fused, i.e. the test can
assert that every instruction requires at least one uop, and IIUC, actually
executing a uop requires an available slot at _some_ time.

diff --git a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
index ae5f6042f1e8..29609b52f8fa 100644
--- a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
+++ b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
@@ -119,6 +119,9 @@ static void guest_assert_event_count(uint8_t idx,
        case INTEL_ARCH_REFERENCE_CYCLES_INDEX:
                GUEST_ASSERT_NE(count, 0);
                break;
+       case INTEL_ARCH_TOPDOWN_SLOTS_INDEX:
+               GUEST_ASSERT(count >= NUM_INSNS_RETIRED);
+               break;
        default:
                break;
        }

Re: [PATCH] KVM: selftests: Test top-down slots event

[Mi, Dapeng]

On 2/3/2024 1:24 AM, Sean Christopherson wrote:
> On Fri, Feb 02, 2024, Dapeng Mi wrote:
>> On 2/2/2024 2:02 AM, Sean Christopherson wrote:
>>> On Thu, Feb 01, 2024, Dapeng Mi wrote:
>>>> Although the fixed counter 3 and the exclusive pseudo slots events is
>>>> not supported by KVM yet, the architectural slots event is supported by
>>>> KVM and can be programed on any GP counter. Thus add validation for this
>>>> architectural slots event.
>>>>
>>>> Top-down slots event "counts the total number of available slots for an
>>>> unhalted logical processor, and increments by machine-width of the
>>>> narrowest pipeline as employed by the Top-down Microarchitecture
>>>> Analysis method." So suppose the measured count of slots event would be
>>>> always larger than 0.
>>> Please translate that into something non-perf folks can understand.  I know what
>>> a pipeline slot is, and I know a dictionary's definition of "available" is, but I
>>> still have no idea what this event actually counts.  In other words, I want a
>>> precise definition of exactly what constitutes an "available slot", in verbiage
>>> that anyone with basic understanding of x86 architectures can follow after reading
>>> the whitepaper[*], which is helpful for understanding the concepts, but doesn't
>>> crisply explain what this event counts.
>>>
>>> Examples of when a slot is available vs. unavailable would be extremely helpful.
>>>
>>> [*] https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2023-0/top-down-microarchitecture-analysis-method.html
>> Yeah, indeed, 'slots' is not easily understood from its literal meaning. I
>> also took some time to understand it when I look at this event for the first
>> time. Simply speaking, slots is an abstract concept which indicates how many
>> uops (decoded from instructions) can be processed simultaneously (per cycle)
>> on HW. we assume there is a classic 5-stage pipeline, fetch, decode,
>> execute, memory access and register writeback. In topdown
>> micro-architectural analysis method, the former two stages (fetch/decode) is
>> called front-end and the last three stages are called back-end.
>>
>> In modern Intel processors, a complicated instruction could be decoded into
>> several uops (micro-operations) and so these uops can be processed
>> simultaneously and then improve the performance. Thus, assume a processor
>> can decode and dispatch 4 uops in front-end and execute 4 uops in back-end
>> simultaneously (per-cycle), so we would say this processor has 4 topdown
>> slots per-cycle. If a slot is spare and can be used to process new uop, we
>> say it's available, but if a slot is occupied by a uop for several cycles
>> and not retired (maybe blocked by memory access), we say this slot is stall
>> and unavailable.
> In that case, can't the test assert that the count is at least NUM_INSNS_RETIRED?
> AFAIK, none of the sequences in the measured code can be fused, i.e. the test can
> assert that every instruction requires at least one uop, and IIUC, actually
> executing a uop requires an available slot at _some_ time.


Yeah, looks the instruction sequence can't be marco-fused on x86 
platforms, the slots count should be equal or larger than 
NUM_INSNS_RETIRED.


>
> diff --git a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
> index ae5f6042f1e8..29609b52f8fa 100644
> --- a/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
> +++ b/tools/testing/selftests/kvm/x86_64/pmu_counters_test.c
> @@ -119,6 +119,9 @@ static void guest_assert_event_count(uint8_t idx,
>          case INTEL_ARCH_REFERENCE_CYCLES_INDEX:
>                  GUEST_ASSERT_NE(count, 0);
>                  break;
> +       case INTEL_ARCH_TOPDOWN_SLOTS_INDEX:
> +               GUEST_ASSERT(count >= NUM_INSNS_RETIRED);
> +               break;
>          default:
>                  break;
>          }