From: Ingo Molnar <mingo@kernel.org>
To: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: peterz@infradead.org, mingo@redhat.com, namhyung@kernel.org,
acme@kernel.org, eranian@google.com, mark.rutland@arm.com,
alexander.shishkin@linux.intel.com, jolsa@kernel.org,
irogers@google.com, adrian.hunter@intel.com,
kan.liang@linux.intel.com, tglx@linutronix.de, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
santosh.shukla@amd.com, ananth.narayan@amd.com,
sandipan.das@amd.com
Subject: Re: [PATCH v2 05/10] perf/amd/ibs: Don't allow freq mode event creation through ->config interface
Date: Fri, 6 Dec 2024 10:22:22 +0100 [thread overview]
Message-ID: <Z1LCTtw99YTutYOR@gmail.com> (raw)
In-Reply-To: <abe58150-735f-4d9d-8ff4-a20b0fc6b376@amd.com>
* Ravi Bangoria <ravi.bangoria@amd.com> wrote:
> Hi Ingo,
>
> >> Most perf_event_attr->config bits directly maps to IBS_{FETCH|OP}_CTL
> >> MSR. Since the sample period is programmed in these control registers,
> >> IBS PMU driver allows opening an IBS event by setting sample period
> >> value directly in perf_event_attr->config instead of using explicit
> >> perf_event_attr->sample_period interface.
> >>
> >> However, this logic is not applicable for freq mode events since the
> >> semantics of control register fields are applicable only to fixed
> >> sample period whereas the freq mode event adjusts sample period after
> >> each and every sample. Currently, IBS driver (unintentionally) allows
> >> creating freq mode event via ->config interface, which is semantically
> >> wrong as well as detrimental because it can be misused to bypass
> >> perf_event_max_sample_rate checks.
> >
> > Then let's fix those rate checks?
> >
> > AFAICS this patch limits functionality because the IBS driver would
> > have to be fixed/enhanced to support frequency based events?
> >
> > I'd strongly favor fixing/enhancing the driver instead, as 'perf top -F
> > 1000' is easy to use and it is a useful concept.
>
> No. This patch does not prevent opening an IBS event in freq mode. User
> can still open freq mode IBS event with usual interface attr->freq=1 and
> attr->sample_freq=<freq>. i.e. 'perf top -F 1000' with IBS event will
> work fine with this patch.
Oh, I see - the regular tooling uses perf_event_attr->sample_period, right?
Never mind then.
Thanks,
Ingo
next prev parent reply other threads:[~2024-12-06 9:22 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-06 5:17 [PATCH v2 00/10] perf/amd/ibs: Fix sample period computations Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 01/10] perf/amd/ibs: Remove IBS_{FETCH|OP}_CONFIG_MASK macros Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 02/10] perf/amd/ibs: Remove pointless sample period check Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 03/10] perf/amd/ibs: Fix ->config to sample period calculation for OP pmu Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 04/10] perf/amd/ibs: Fix perf_ibs_op.cnt_mask for CurCnt Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 05/10] perf/amd/ibs: Don't allow freq mode event creation through ->config interface Ravi Bangoria
2024-12-06 8:47 ` Ingo Molnar
2024-12-06 9:07 ` Ravi Bangoria
2024-12-06 9:22 ` Ingo Molnar [this message]
2024-12-06 9:38 ` Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 06/10] perf/amd/ibs: Add pmu specific minimum period Ravi Bangoria
2024-12-06 8:42 ` Ingo Molnar
2024-12-06 8:47 ` Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 07/10] perf/amd/ibs: Add ->check_period() callback Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 08/10] perf/core: Introduce pmu->adjust_period() callback Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 09/10] perf test: Introduce DEFINE_SUITE_EXCLUSIVE() Ravi Bangoria
2024-12-06 5:17 ` [PATCH v2 10/10] perf test amd ibs: Add sample period unit test Ravi Bangoria
2024-12-06 5:24 ` Ravi Bangoria
2024-12-06 8:43 ` Ingo Molnar
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=Z1LCTtw99YTutYOR@gmail.com \
--to=mingo@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=ananth.narayan@amd.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=eranian@google.com \
--cc=hpa@zytor.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--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=ravi.bangoria@amd.com \
--cc=sandipan.das@amd.com \
--cc=santosh.shukla@amd.com \
--cc=tglx@linutronix.de \
--cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.