From: Andi Kleen <ak@linux.intel.com>
To: Ben Gainey <ben.gainey@arm.com>
Cc: peterz@infradead.org, mingo@redhat.com, acme@kernel.org,
namhyung@kernel.org, will@kernel.org, james.clark@arm.com,
mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 0/4] A mechanism for efficient support for per-function metrics
Date: Tue, 23 Apr 2024 08:42:42 -0700 [thread overview]
Message-ID: <ZifW8rZk41t4ukIV@tassilo> (raw)
In-Reply-To: <20240422104929.264241-1-ben.gainey@arm.com>
> Cursory testing on a Xeon(R) W-2145 with a 300 *instruction* sample
> window (with and without the patch) suggests this approach would work
> for some counters. Calculating branch miss rates for example appears to
> be correct when used with the instruction counter as the sampling event,
> or at least this approach correctly identifies which functions in the
> test benchmark are prone to poor predictability. On the other hand the
> combination cycle and instructions counter does not appear to sample
> correctly as a pair. With something like
>
> perf record -e '{cycles/period=999700,alt-period=300/,instructions}:uS' ... benchmark
>
> I often see very large CPI, the same affect is observed without the
> patch enabled. No idea whats going on there, so any insight welcome...
My guess would be that the PMI handler cleared L1 and there are stalls
reloading the working set. You can check L1 miss events to confirm.
Unfortunately with the period change it cannot use multi-record
PEBS which would avoid the need for a PMI.
-Andi
next prev parent reply other threads:[~2024-04-23 15:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 10:49 [RFC PATCH v2 0/4] A mechanism for efficient support for per-function metrics Ben Gainey
2024-04-22 10:49 ` [RFC PATCH v2 1/4] perf: Allow periodic events to alternate between two sample periods Ben Gainey
2024-04-22 10:49 ` [RFC PATCH v2 2/4] perf: Allow adding fixed random jitter to the alternate sampling period Ben Gainey
2024-04-22 13:08 ` James Clark
2024-04-22 14:40 ` Ben Gainey
2024-04-23 9:55 ` James Clark
2024-04-22 10:49 ` [RFC PATCH v2 3/4] tools/perf: Modify event parser to support alt-period term Ben Gainey
2024-04-22 10:49 ` [RFC PATCH v2 4/4] tools/perf: Modify event parser to support alt-period-jitter term Ben Gainey
2024-04-23 15:42 ` Andi Kleen [this message]
2024-04-26 11:11 ` [RFC PATCH v2 0/4] A mechanism for efficient support for per-function metrics Ben Gainey
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=ZifW8rZk41t4ukIV@tassilo \
--to=ak@linux.intel.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=ben.gainey@arm.com \
--cc=irogers@google.com \
--cc=james.clark@arm.com \
--cc=jolsa@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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=will@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).