public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: Ian Rogers <irogers@google.com>
Cc: Falcon Thomas <thomas.falcon@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	Zide Chen <zide.chen@intel.com>, Dapeng Mi <dapeng1.mi@intel.com>,
	Xudong Hao <xudong.hao@intel.com>
Subject: Re: [PATCH] perf tests: Add auto counter reload (ACR) sampling test
Date: Thu, 16 Apr 2026 11:06:09 +0800	[thread overview]
Message-ID: <52a669dd-243c-4956-855e-ae76f6951ec4@linux.intel.com> (raw)
In-Reply-To: <CAP-5=fWj4PaadfdmkoNyOVnbNb9aAdhgxOr-CG+R8OLx2jFRCg@mail.gmail.com>


On 4/16/2026 1:13 AM, Ian Rogers wrote:
> On Wed, Apr 15, 2026 at 2:19 AM Mi, Dapeng <dapeng1.mi@linux.intel.com> wrote:
>>
>> On 4/13/2026 9:30 AM, Ian Rogers wrote:
>>> On Sun, Apr 12, 2026 at 6:14 PM Dapeng Mi <dapeng1.mi@linux.intel.com> wrote:
>>>> Add auto counter reload sampling test to verify that the intended event
>>>> records can be captured and the self-reloaded events won't generate any
>>>> records.
>>>>
>>>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>>>> ---
>>>>  tools/perf/tests/shell/record.sh | 42 ++++++++++++++++++++++++++++++++
>>>>  1 file changed, 42 insertions(+)
>>>>
>>>> diff --git a/tools/perf/tests/shell/record.sh b/tools/perf/tests/shell/record.sh
>>>> index 7cb81cf3444a..1068843282f5 100755
>>>> --- a/tools/perf/tests/shell/record.sh
>>>> +++ b/tools/perf/tests/shell/record.sh
>>>> @@ -402,6 +402,47 @@ test_callgraph() {
>>>>    echo "Callgraph test [Success]"
>>>>  }
>>>>
>>>> +test_acr_sampling() {
>>>> +  events="{instructions/period=20000,acr_mask=0x2/u,cycles/period=40000,acr_mask=0x3/u}"
>>>> +  pebs_events="{instructions/period=20000,acr_mask=0x2/pu,cycles/period=40000,acr_mask=0x3/u}"
>>>> +  echo "Auto counter reload sampling test"
>>>> +  if ! perf record -o "${perfdata}" -e "${events}" ${testprog} 2> /dev/null
>>>> +  then
>>>> +    echo "Auto counter reload sampling [Skipped not supported]"
>>>> +    return
>>>> +  fi
>>>> +  if ! perf script -i "${perfdata}" | grep -q "period=20000,acr_mask=0x2"
>>>> +  then
>>>> +    echo "Auto counter reload sampling [Failed missing instructions event]"
>>>> +    err=1
>>>> +    return
>>>> +  fi
>>>> +  if perf script -i "${perfdata}" | grep -q "period=40000,acr_mask=0x3"
>>>> +  then
>>>> +    echo "Auto counter reload sampling [Failed cycles event shouldn't be sampled]"
>>>> +    err=1
>>>> +    return
>>>> +  fi
>>>> +  if ! perf record -o "${perfdata}" -e "${pebs_events}" ${testprog} 2> /dev/null
>>>> +  then
>>>> +    echo "Auto counter reload PEBS sampling [Skipped not supported]"
>>>> +    return
>>>> +  fi
>>>> +  if ! perf script -i "${perfdata}" | grep -q "period=20000,acr_mask=0x2"
>>>> +  then
>>>> +    echo "Auto counter reload PEBS sampling [Failed missing instructions event]"
>>>> +    err=1
>>>> +    return
>>>> +  fi
>>>> +  if perf script -i "${perfdata}" | grep -q "period=40000,acr_mask=0x3"
>>>> +  then
>>>> +    echo "Auto counter reload PEBS sampling [Failed cycles event shouldn't be sampled]"
>>>> +    err=1
>>>> +    return
>>>> +  fi
>>>> +  echo "Auto counter reload sampling [Success]"
>>> Thanks Dapeng! Could we also test ratio-to-prev as well as just the
>>> plain acr_mask?
>> Ian, it could be hard to validate ratio-to-prev option in this test. On
>> platforms which don't support ACR, perf would automatically fallback the
>> ACR sampling to normal sampling, this would lead to false positives on
>> checking the existence of records from cycles event. I didn't find a good
>> way to figure out this fallback.
>>
>> Since we already have independent test case to validate the ratio_to_prev
>> parsing. It may be unnecessary to add ratio-to-prev validation in this ACR
>> test.
> So the ratio_to_prev test covers parsing the ratio-to-prev option (it
> only has `perf record` commands) and ensures it is acted upon, but it
> doesn't check the option's functional behavior - what the output is.
> This test makes sure the acr_mask option is functional and so would be
> complemented by ratio-to-prev testing somethig like:
> ```
>   rtp_events="{instructions,cycles/period=40000,ratio-to-prev=0.5/u}"
>
>   # Test ratio-to-prev
>   if ! perf record -o "${perfdata}" -e "${rtp_events}" ${testprog} 2> /dev/null
>   then
>     echo "Auto counter reload ratio-to-prev sampling [Failed record
> ratio-to-prev]"
>     err=1
>     return
>   fi
>   if ! perf script -i "${perfdata}" | grep -q "instructions"
>   then
>     echo "Auto counter reload ratio-to-prev sampling [Failed missing
> instructions event]"
>     err=1
>     return
>   fi
>   if perf script -i "${perfdata}" | grep -q "cycles"
>   then
>     echo "Auto counter reload ratio-to-prev sampling [Failed cycles
> event shouldn't be sampled]"
>     err=1
>     return
>   fi
> ```
> The first thing your test does is to make sure the acr_mask is
> supported, so I'm not sure how the fall back can happen?
> We could additionally check for
> `/sys/bus/event_source/devices/cpu*/format/acr_mask`.

Yes, that's initially what I intended to do, but it would cause false
positives on some hybrid platform, like PTL which only supports ACR on E-core.

```

$ grep . /sys/bus/event_source/devices/cpu_core/format/*
/sys/bus/event_source/devices/cpu_core/format/cmask:config:24-31
/sys/bus/event_source/devices/cpu_core/format/edge:config:18
/sys/bus/event_source/devices/cpu_core/format/eq:config:36
/sys/bus/event_source/devices/cpu_core/format/event:config:0-7
/sys/bus/event_source/devices/cpu_core/format/frontend:config1:0-23
/sys/bus/event_source/devices/cpu_core/format/inv:config:23
/sys/bus/event_source/devices/cpu_core/format/ldlat:config1:0-15
/sys/bus/event_source/devices/cpu_core/format/metrics_clear:config1:0
/sys/bus/event_source/devices/cpu_core/format/offcore_rsp:config1:0-63
/sys/bus/event_source/devices/cpu_core/format/pc:config:19
/sys/bus/event_source/devices/cpu_core/format/umask:config:8-15,40-47

$ grep . /sys/bus/event_source/devices/cpu_atom/format/*
/sys/bus/event_source/devices/cpu_atom/format/acr_mask:config2:0-63
/sys/bus/event_source/devices/cpu_atom/format/cmask:config:24-31
/sys/bus/event_source/devices/cpu_atom/format/edge:config:18
/sys/bus/event_source/devices/cpu_atom/format/eq:config:36
/sys/bus/event_source/devices/cpu_atom/format/event:config:0-7
/sys/bus/event_source/devices/cpu_atom/format/inv:config:23
/sys/bus/event_source/devices/cpu_atom/format/ldlat:config1:0-15
/sys/bus/event_source/devices/cpu_atom/format/offcore_rsp:config1:0-63
/sys/bus/event_source/devices/cpu_atom/format/pc:config:19
/sys/bus/event_source/devices/cpu_atom/format/snoop_rsp:config1:0-63
/sys/bus/event_source/devices/cpu_atom/format/umask:config:8-15,40-47

```

So strictly speaking, we need to check if it's a hybrid platform first and
then check if the exact P-core/E-core supports ACR, then run the above ACR
tests. It seems a little bit over-complicated and I'm not sure if it's
accepted to add so much Intel specific check in the record.sh.

How's your idea on this? Thanks.


>
> Thanks,
> Ian
>
>>> Thanks,
>>> Ian
>>>
>>>> +}
>>>> +
>>>>  test_ratio_to_prev() {
>>>>    echo "ratio-to-prev test"
>>>>    if ! perf record -o /dev/null -e "{instructions, cycles/period=100000,ratio-to-prev=0.5/}" \
>>>> @@ -457,6 +498,7 @@ test_leader_sampling
>>>>  test_topdown_leader_sampling
>>>>  test_precise_max
>>>>  test_callgraph
>>>> +test_acr_sampling
>>>>  test_ratio_to_prev
>>>>
>>>>  # restore the default value
>>>>
>>>> base-commit: 4e03d6494f9504f8af46ba68a2a8b6877c196789
>>>> --
>>>> 2.34.1
>>>>

  reply	other threads:[~2026-04-16  3:06 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-13  1:09 [PATCH] perf tests: Add auto counter reload (ACR) sampling test Dapeng Mi
2026-04-13  1:30 ` Ian Rogers
2026-04-13  1:35   ` Mi, Dapeng
2026-04-15  9:19   ` Mi, Dapeng
2026-04-15 17:13     ` Ian Rogers
2026-04-16  3:06       ` Mi, Dapeng [this message]
2026-04-16  3:17         ` Ian Rogers
2026-04-16  3:25           ` Mi, Dapeng

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=52a669dd-243c-4956-855e-ae76f6951ec4@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=dapeng1.mi@intel.com \
    --cc=irogers@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=thomas.falcon@intel.com \
    --cc=xudong.hao@intel.com \
    --cc=zide.chen@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