From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Jim Mattson <jmattson@google.com>
Cc: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Zhang Xiong <xiong.y.zhang@intel.com>,
Mingwei Zhang <mizhang@google.com>,
Like Xu <like.xu.linux@gmail.com>,
Dapeng Mi <dapeng1.mi@intel.com>
Subject: Re: [kvm-unit-tests Patch 2/5] x86: pmu: Change the minimum value of llc_misses event to 0
Date: Wed, 25 Oct 2023 19:22:55 +0800 [thread overview]
Message-ID: <6132ba52-fdf1-4680-9e4e-5ea2fcb63b3c@linux.intel.com> (raw)
In-Reply-To: <CALMp9eRqGr+5+C1OLhxv1i8Q=YVRmFxkZQJoh7HzWkPg2z=WoA@mail.gmail.com>
On 10/24/2023 9:03 PM, Jim Mattson wrote:
> On Tue, Oct 24, 2023 at 12:51 AM Dapeng Mi <dapeng1.mi@linux.intel.com> wrote:
>> Along with the CPU HW's upgrade and optimization, the count of LLC
>> misses event for running loop() helper could be 0 just like seen on
>> Sapphire Rapids.
>>
>> So modify the lower limit of possible count range for LLC misses
>> events to 0 to avoid LLC misses event test failure on Sapphire Rapids.
> I'm not convinced that these tests are really indicative of whether or
> not the PMU is working properly. If 0 is allowed for llc misses, for
> instance, doesn't this sub-test pass even when the PMU is disabled?
>
> Surely, we can do better.
Considering the testing workload is just a simple adding loop, it's
reasonable and possible that it gets a 0 result for LLC misses and
branch misses events. Yeah, I agree the 0 count makes the results not so
credible. If we want to avoid these 0 count values, we may have to
complicate the workload, such as adding flush cache instructions, or
something like that (I'm not sure if there are instructions which can
force branch misses). How's your idea about this?
>
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> ---
>> x86/pmu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/x86/pmu.c b/x86/pmu.c
>> index 0def28695c70..7443fdab5c8a 100644
>> --- a/x86/pmu.c
>> +++ b/x86/pmu.c
>> @@ -35,7 +35,7 @@ struct pmu_event {
>> {"instructions", 0x00c0, 10*N, 10.2*N},
>> {"ref cycles", 0x013c, 1*N, 30*N},
>> {"llc references", 0x4f2e, 1, 2*N},
>> - {"llc misses", 0x412e, 1, 1*N},
>> + {"llc misses", 0x412e, 0, 1*N},
>> {"branches", 0x00c4, 1*N, 1.1*N},
>> {"branch misses", 0x00c5, 0, 0.1*N},
>> }, amd_gp_events[] = {
>> --
>> 2.34.1
>>
next prev parent reply other threads:[~2023-10-25 11:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 7:57 [kvm-unit-tests Patch 0/5] Fix PMU test failures on Sapphire Rapids Dapeng Mi
2023-10-24 7:57 ` [kvm-unit-tests Patch 1/5] x86: pmu: Remove duplicate code in pmu_init() Dapeng Mi
2023-10-24 7:57 ` [kvm-unit-tests Patch 2/5] x86: pmu: Change the minimum value of llc_misses event to 0 Dapeng Mi
2023-10-24 13:03 ` Jim Mattson
2023-10-25 11:22 ` Mi, Dapeng [this message]
2023-10-25 12:35 ` Jim Mattson
2023-10-26 2:14 ` Mi, Dapeng
2023-10-26 12:19 ` Jim Mattson
2023-10-27 10:17 ` Mi, Dapeng
2023-10-24 7:57 ` [kvm-unit-tests Patch 3/5] x86: pmu: Enlarge cnt array length to 64 in check_counters_many() Dapeng Mi
2023-10-24 7:57 ` [kvm-unit-tests Patch 4/5] x86: pmu: Support validation for Intel PMU fixed counter 3 Dapeng Mi
2023-10-24 19:05 ` Jim Mattson
2023-10-25 11:26 ` Mi, Dapeng
2023-10-25 12:38 ` Jim Mattson
2023-10-26 2:29 ` Mi, Dapeng
2023-10-24 7:57 ` [kvm-unit-tests Patch 5/5] x86: pmu: Add asserts to warn inconsistent fixed events and counters Dapeng Mi
2023-10-25 23:47 ` [kvm-unit-tests Patch 0/5] Fix PMU test failures on Sapphire Rapids Mingwei Zhang
2023-10-26 3:32 ` Mi, Dapeng
2023-10-30 3:57 ` Mingwei Zhang
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=6132ba52-fdf1-4680-9e4e-5ea2fcb63b3c@linux.intel.com \
--to=dapeng1.mi@linux.intel.com \
--cc=dapeng1.mi@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mizhang@google.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=xiong.y.zhang@intel.com \
--cc=zhenyuw@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox