linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@linaro.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: mark.rutland@arm.com, will@kernel.org,
	alexander.shishkin@linux.intel.com, catalin.marinas@arm.com,
	jolsa@redhat.com, adrian.hunter@intel.com, acme@kernel.org,
	linux-kernel@vger.kernel.org, zhangshaokun@hisilicon.com,
	peterz@infradead.org, mingo@redhat.com, James.Clark@arm.com,
	guohanjun@huawei.com, namhyung@kernel.org, liwei391@huawei.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/4] drivers/perf: Add support for ARMv8.3-SPE
Date: Thu, 30 Jul 2020 16:14:58 +0800	[thread overview]
Message-ID: <20200730081458.GA23324@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <a9c59cb6-80f7-1abe-cef4-33127f051488@arm.com>

Hi Suzuki,

On Wed, Jul 29, 2020 at 10:12:50AM +0100, Suzuki Kuruppassery Poulose wrote:
> On 07/24/2020 10:16 AM, Wei Li wrote:
> > Armv8.3 extends the SPE by adding:
> > - Alignment field in the Events packet, and filtering on this event
> >    using PMSEVFR_EL1.
> > - Support for the Scalable Vector Extension (SVE).
> > 
> > The main additions for SVE are:
> > - Recording the vector length for SVE operations in the Operation Type
> >    packet. It is not possible to filter on vector length.
> > - Incomplete predicate and empty predicate fields in the Events packet,
> >    and filtering on these events using PMSEVFR_EL1.
> > 
> > Update the check of pmsevfr for empty/partial predicated SVE and
> > alignment event in kernel driver.
> > 
> > Signed-off-by: Wei Li <liwei391@huawei.com>
> > ---
> >   arch/arm64/include/asm/sysreg.h |  4 +++-
> >   drivers/perf/arm_spe_pmu.c      | 18 ++++++++++++++----
> >   2 files changed, 17 insertions(+), 5 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> > index 463175f80341..be4c44ccdb56 100644
> > --- a/arch/arm64/include/asm/sysreg.h
> > +++ b/arch/arm64/include/asm/sysreg.h
> > @@ -281,7 +281,6 @@
> >   #define SYS_PMSFCR_EL1_ST_SHIFT		18
> >   #define SYS_PMSEVFR_EL1			sys_reg(3, 0, 9, 9, 5)
> > -#define SYS_PMSEVFR_EL1_RES0		0x0000ffff00ff0f55UL
> >   #define SYS_PMSLATFR_EL1		sys_reg(3, 0, 9, 9, 6)
> >   #define SYS_PMSLATFR_EL1_MINLAT_SHIFT	0
> > @@ -769,6 +768,9 @@
> >   #define ID_AA64DFR0_PMUVER_8_5		0x6
> >   #define ID_AA64DFR0_PMUVER_IMP_DEF	0xf
> > +#define ID_AA64DFR0_PMSVER_8_2		0x1
> > +#define ID_AA64DFR0_PMSVER_8_3		0x2
> > +
> >   #define ID_DFR0_PERFMON_SHIFT		24
> >   #define ID_DFR0_PERFMON_8_1		0x4
> > diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
> > index e51ddb6d63ed..5ec7ee0c8fa1 100644
> > --- a/drivers/perf/arm_spe_pmu.c
> > +++ b/drivers/perf/arm_spe_pmu.c
> > @@ -54,7 +54,7 @@ struct arm_spe_pmu {
> >   	struct hlist_node			hotplug_node;
> >   	int					irq; /* PPI */
> > -
> > +	int					pmuver;
> >   	u16					min_period;
> >   	u16					counter_sz;
> > @@ -80,6 +80,15 @@ struct arm_spe_pmu {
> >   /* Keep track of our dynamic hotplug state */
> >   static enum cpuhp_state arm_spe_pmu_online;
> > +static u64 sys_pmsevfr_el1_mask[] = {
> > +	[ID_AA64DFR0_PMSVER_8_2] = GENMASK_ULL(63, 48) | GENMASK_ULL(31, 24) |
> > +		GENMASK_ULL(15, 12) | BIT_ULL(7) | BIT_ULL(5) | BIT_ULL(3) |
> > +		BIT_ULL(1),
> > +	[ID_AA64DFR0_PMSVER_8_3] = GENMASK_ULL(63, 48) | GENMASK_ULL(31, 24) |
> > +		GENMASK_ULL(18, 17) | GENMASK_ULL(15, 11) | BIT_ULL(7) |
> > +		BIT_ULL(5) | BIT_ULL(3) | BIT_ULL(1),
> > +};
> > +
> >   enum arm_spe_pmu_buf_fault_action {
> >   	SPE_PMU_BUF_FAULT_ACT_SPURIOUS,
> >   	SPE_PMU_BUF_FAULT_ACT_FATAL,
> > @@ -670,7 +679,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event)
> >   	    !cpumask_test_cpu(event->cpu, &spe_pmu->supported_cpus))
> >   		return -ENOENT;
> > -	if (arm_spe_event_to_pmsevfr(event) & SYS_PMSEVFR_EL1_RES0)
> > +	if (arm_spe_event_to_pmsevfr(event) & ~sys_pmsevfr_el1_mask[spe_pmu->pmuver])
> >   		return -EOPNOTSUPP;
> >   	if (attr->exclude_idle)
> > @@ -937,6 +946,7 @@ static void __arm_spe_pmu_dev_probe(void *info)
> >   			fld, smp_processor_id());
> >   		return;
> >   	}
> > +	spe_pmu->pmuver = fld;
> 
> How do we deal with cases where we have big.LITTLE system with differing
> SPE versions ?

Good point.

The first question we need to answer is: how to define SPE version?
From my understanding, if SPE uses the same sample specification and
the same packet format, then we should consider the SPE is the same
version cross CPUs.  So even some CPUs are ARMv8.2 and other CPUs are
ARMv8.3 variants, we still should take the SPE as the same version.

And when read the SPE driver in the file drivers/perf/arm_spe_pmu.c and
I concluded that so far the SPE perf driver is to only support SPE-v1
with single instance, it cannot support a complex usage case like
below:

  CPU0-3: ARMv8.2 architecture with SPE
  CPU4-7: ARMv8.3 architecture with SPE

For this case, if we take SPE as two different versions, let's say
SPE-8.2 and SPE-8.3, then should the SPE driver need to create multi
perf PMU events?  For example, we should create a perf PMU event
'arm_spe_8.2' and another PMU event 'arm_spe_8.3'.

Another option is we always take this as SPE-v1 and only create single
PMU event, just keep what's we are doing with the perf event
'arm_spe_0', but the driver needs to dynamically detect SPE PMU version
number in the function arm_spe_pmu_event_init(), and then based on
version number to select corresponding mask for PMSEVFR.

Thanks,
Leo

[1] https://lore.kernel.org/linux-arm-kernel/20200724071111.35593-1-liwei391@huawei.com/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-07-30  8:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-24  9:16 [PATCH 0/4] Add support for ARMv8.3-SPE Wei Li
2020-07-24  9:16 ` [PATCH 1/4] drivers/perf: " Wei Li
2020-07-28 12:27   ` Leo Yan
2020-07-28 13:24     ` liwei (GF)
2020-07-29  7:08       ` Leo Yan
2020-07-29  9:12   ` Suzuki K Poulose
2020-07-30  8:14     ` Leo Yan [this message]
2020-07-31 12:18       ` liwei (GF)
2020-07-31 14:01         ` Suzuki K Poulose
2020-09-07 12:51   ` Will Deacon
2020-09-29  8:17     ` liwei (GF)
2020-07-24  9:16 ` [PATCH 2/4] perf: arm-spe: " Wei Li
2020-07-29  6:29   ` Leo Yan
2020-07-29  7:21     ` liwei (GF)
2020-07-29  7:28       ` Leo Yan
2020-07-29  7:42         ` liwei (GF)
2020-08-17 15:04   ` Leo Yan
2020-07-24  9:16 ` [PATCH 3/4] perf auxtrace: Add new itrace options " Wei Li
2020-07-29  6:51   ` Leo Yan
2020-07-24  9:16 ` [PATCH 4/4] perf: arm-spe: Synthesize new events " Wei Li
2020-07-28 12:06 ` [PATCH 0/4] Add support " Arnaldo Carvalho de Melo
2020-07-28 12:41   ` Leo Yan

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=20200730081458.GA23324@leoy-ThinkPad-X240s \
    --to=leo.yan@linaro.org \
    --cc=James.Clark@arm.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liwei391@huawei.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    --cc=zhangshaokun@hisilicon.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;
as well as URLs for NNTP newsgroup(s).