linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Oliver Upton <oliver.upton@linux.dev>,
	Peter Zijlstra <peterz@infradead.org>,
	Ravi Bangoria <ravi.bangoria@amd.com>,
	Nathan Chancellor <nathan@kernel.org>,
	namhyung@kernel.org, eranian@google.com, acme@kernel.org,
	mark.rutland@arm.com, jolsa@kernel.org, bp@alien8.de,
	kan.liang@linux.intel.com, adrian.hunter@intel.com,
	maddy@linux.ibm.com, x86@kernel.org,
	linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
	sandipan.das@amd.com, ananth.narayan@amd.com,
	santosh.shukla@amd.com, kvmarm@lists.linux.dev
Subject: Re: [PATCH v4 3/4] perf/core: Remove pmu linear searching code
Date: Sat, 27 May 2023 14:32:51 +0100	[thread overview]
Message-ID: <86jzwtdhmk.wl-maz@kernel.org> (raw)
In-Reply-To: <CAP-5=fWYbzmTETgqJ11y22=JaXDM0gnb4qR6KYeRGmFXw08f-Q@mail.gmail.com>

On Sat, 27 May 2023 00:00:47 +0100,
Ian Rogers <irogers@google.com> wrote:
> 
> On Thu, May 25, 2023 at 8:56 AM Oliver Upton <oliver.upton@linux.dev> wrote:
> >
> > On Thu, May 25, 2023 at 04:20:31PM +0200, Peter Zijlstra wrote:
> > > On Thu, May 25, 2023 at 07:11:41AM +0000, Oliver Upton wrote:
> > >
> > > > The PMUv3 driver does pass a name, but it relies on getting back an
> > > > allocated pmu id as @type is -1 in the call to perf_pmu_register().
> > > >
> > > > What actually broke is how KVM probes for a default core PMU to use for
> > > > a guest. kvm_pmu_probe_armpmu() creates a counter w/ PERF_TYPE_RAW and
> > > > reads the pmu from the returned perf_event. The linear search had the
> > > > effect of eventually stumbling on the correct core PMU and succeeding.
> > > >
> > > > Perf folks: is this WAI for heterogenous systems?
> > >
> > > TBH, I'm not sure. hetero and virt don't mix very well AFAIK and I'm not
> > > sure what ARM64 does here.
> > >
> > > IIRC the only way is to hard affine things; that is, force vCPU of
> > > 'type' to the pCPU mask of 'type' CPUs.
> >
> > We provide absolutely no illusion of consistency across implementations.
> > Userspace can select the PMU type, and then it is a userspace problem
> > affining vCPUs to the right pCPUs.
> >
> > And if they get that wrong, we just bail and refuse to run the vCPU.
> >
> > > If you don't do that; or let userspace 'override' that, things go
> > > sideways *real* fast.
> >
> > Oh yeah, and I wish PMUs were the only problem with these hetero
> > systems...
> 
> Just to add some context from what I understand. There are inbuilt
> type numbers for PMUs:
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/include/uapi/linux/perf_event.h?h=perf-tools-next#n34
> so the PMU generally called /sys/devices/cpu should have type 4 (ARM
> give it another name). For heterogeneous ARM there is a single PMU and
> the same events are programmed regardless of whether it is a big or a
> little core - the cpumask lists all CPUs.

I think you misunderstood the way heterogeneous arm64 systems are
described . Each CPU type gets its own PMU type, and its own event
list. Case in point:

$ grep . /sys/devices/*pmu/{type,cpus}
/sys/devices/apple_avalanche_pmu/type:9
/sys/devices/apple_blizzard_pmu/type:8
/sys/devices/apple_avalanche_pmu/cpus:4-9
/sys/devices/apple_blizzard_pmu/cpus:0-3

Type 4 (aka PERF_EVENT_RAW) is AFAICT just a way to encode the raw
event number, nothing else.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2023-05-27 13:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-04 10:59 [PATCH v4 0/4] perf: Rework event forwarding logic Ravi Bangoria
2023-05-04 11:00 ` [PATCH v4 1/4] perf/core: Rework forwarding of {task|cpu}-clock events Ravi Bangoria
2024-02-20  8:41   ` Pengfei Xu
2024-02-23  5:27     ` Ravi Bangoria
2024-02-28 12:49       ` Ravi Bangoria
2024-02-29  3:41         ` Pengfei Xu
2023-05-04 11:00 ` [PATCH v4 2/4] perf/ibs: Fix interface via core pmu events Ravi Bangoria
2023-05-04 11:00 ` [PATCH v4 3/4] perf/core: Remove pmu linear searching code Ravi Bangoria
2023-05-24 21:41   ` Nathan Chancellor
2023-05-25  5:16     ` Ravi Bangoria
2023-05-25  7:11       ` Oliver Upton
2023-05-25 14:20         ` Peter Zijlstra
2023-05-25 15:56           ` Oliver Upton
2023-05-26 23:00             ` Ian Rogers
2023-05-27 13:32               ` Marc Zyngier [this message]
2023-05-27 17:00                 ` Ian Rogers
2023-05-27 17:05                   ` Ian Rogers
2023-05-27 18:38                   ` Marc Zyngier
2023-05-27 19:50                     ` Ian Rogers
2023-05-30  7:45                     ` Thomas Richter
2023-05-30 14:00                       ` Ian Rogers
2023-05-31  9:09                         ` Thomas Richter
     [not found]                           ` <CAP-5=fVw3vSEu7yGFDnZi8c3VUFJu_XEZtY9ZcTsD7ip2imR6Q@mail.gmail.com>
2023-06-01 11:02                             ` Thomas Richter
2023-06-01 11:18                               ` Peter Zijlstra
2023-06-01 11:20                                 ` Peter Zijlstra
2023-05-25 15:55         ` Nathan Chancellor
2023-05-04 11:00 ` [PATCH v4 4/4] perf test: Add selftest to test IBS invocation via core pmu events Ravi Bangoria
2023-05-05  9:16   ` Peter Zijlstra
2023-05-15 21:31     ` Arnaldo Carvalho de Melo
2023-05-15 21:33       ` Arnaldo Carvalho de Melo

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=86jzwtdhmk.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ananth.narayan@amd.com \
    --cc=bp@alien8.de \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=mark.rutland@arm.com \
    --cc=namhyung@kernel.org \
    --cc=nathan@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@amd.com \
    --cc=sandipan.das@amd.com \
    --cc=santosh.shukla@amd.com \
    --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 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).