linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Hanjun Guo <guohanjun@huawei.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>,
	linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
	catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net,
	lenb@kernel.org, mark.rutland@arm.com, lorenzo.pieralisi@arm.com,
	linuxarm@huawei.com, john.garry@huawei.com,
	Sudeep Holla <sudeep.holla@arm.com>
Subject: Re: [PATCH v3 0/5] arm64: SPE ACPI enablement
Date: Wed, 8 May 2019 17:45:06 +0100	[thread overview]
Message-ID: <20190508164506.GA21553@e107155-lin> (raw)
In-Reply-To: <5eaa1607-4bf0-a320-e9cf-2d51eca912c6@huawei.com>

On Sat, May 04, 2019 at 07:06:19PM +0800, Hanjun Guo wrote:
> Hi Jeremy, Mark,
>
> On 2019/5/4 7:24, Jeremy Linton wrote:
> > This patch series enables the Arm Statistical Profiling
> > Extension (SPE) on ACPI platforms.
> >
> > This is possible because ACPI 6.3 uses a previously
> > reserved field in the MADT to store the SPE interrupt
> > number, similarly to how the normal PMU is described.
> > If a consistent valid interrupt exists across all the
> > cores in the system, a platform device is registered.
> > That then triggers the SPE module, which runs as normal.
> >
> > We also add the ability to parse the PPTT for IDENTICAL
> > cores. We then use this to sanity check the single SPE
> > device we create. This creates a bit of a problem with
> > respect to the specification though. The specification
> > says that its legal for multiple tree's to exist in the
> > PPTT. We handle this fine, but what happens in the
> > case of multiple tree's is that the lack of a common
> > node with IDENTICAL set forces us to assume that there
> > are multiple non-IDENTICAL cores in the machine.
>
> Adding this patch set on top of latest mainline kernel,
> and tested on D06 which has the SPE feature, in boot message
> shows it was probed successfully:
>
> arm_spe_pmu arm,spe-v1: probed for CPUs 0-95 [max_record_sz 128, align 4, features 0x7]
>
> but when I test it with spe events such as
>
> perf record -c 1024 -e arm_spe_0/branch_filter=0/ -o spe ls
>
> it fails with:
> failed to mmap with 12 (Cannot allocate memory),
>
> Confirmed that patch [0] is merged and other perf events are working
> fine.
>
> I narrowed this issue down that mmap() failed to alloc 4M memory
> in perf tool but seems have no relationship with this SPE patch set,
> then I'm lost, could you take look please?
>

Thanks for pointing this out. I had last tested SPE only with v5.0 and
missed completely to check on v5.1. FWIW, I can reproduce this issue
on v5.1

--
Regards,
Sudeep

      parent reply	other threads:[~2019-05-08 16:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-03 23:24 [PATCH v3 0/5] arm64: SPE ACPI enablement Jeremy Linton
2019-05-03 23:24 ` Jeremy Linton
2019-05-03 23:24 ` [PATCH v3 1/5] ACPI/PPTT: Trivial, change the capitalization of CPU Jeremy Linton
2019-05-03 23:24   ` Jeremy Linton
2019-05-07 18:12   ` Jeremy Linton
2019-05-07 18:12     ` Jeremy Linton
2019-05-03 23:24 ` [PATCH v3 2/5] ACPI/PPTT: Add function to return ACPI 6.3 Identical tokens Jeremy Linton
2019-05-03 23:24   ` Jeremy Linton
2019-05-05  7:09   ` Kefeng Wang
2019-05-05  7:09     ` Kefeng Wang
2019-05-07 18:26     ` Jeremy Linton
2019-05-07 18:26       ` Jeremy Linton
2019-06-07  9:49   ` Sudeep Holla
2019-05-03 23:24 ` [PATCH v3 3/5] ACPI/PPTT: Modify node flag detection to find last IDENTICAL Jeremy Linton
2019-05-03 23:24   ` Jeremy Linton
2019-06-07  9:53   ` Sudeep Holla
2019-06-07 13:15     ` Jeremy Linton
2019-06-07 13:47       ` Sudeep Holla
2019-05-03 23:24 ` [PATCH v3 4/5] arm_pmu: acpi: spe: Add initial MADT/SPE probing Jeremy Linton
2019-05-03 23:24   ` Jeremy Linton
2019-05-08 11:18   ` John Garry
2019-05-08 20:04     ` Jeremy Linton
2019-06-07  9:57   ` Sudeep Holla
2019-06-07 13:28     ` Jeremy Linton
2019-06-07 13:37       ` Sudeep Holla
2019-05-03 23:24 ` [PATCH v3 5/5] perf: arm_spe: Enable ACPI/Platform automatic module loading Jeremy Linton
2019-05-03 23:24   ` Jeremy Linton
2019-05-04 11:06 ` [PATCH v3 0/5] arm64: SPE ACPI enablement Hanjun Guo
2019-05-04 11:06   ` Hanjun Guo
2019-05-07 17:58   ` Jeremy Linton
2019-05-07 17:58     ` Jeremy Linton
2019-05-08  9:35     ` Hanjun Guo
2019-05-08 16:51       ` Sudeep Holla
2019-05-09  9:28         ` Will Deacon
2019-05-09 10:35           ` Sudeep Holla
2019-05-09 14:13             ` Sudeep Holla
2019-05-13 10:56               ` Will Deacon
2019-05-13 11:31                 ` Sudeep Holla
2019-05-13 11:10             ` Hanjun Guo
2019-05-08 16:45   ` Sudeep Holla [this message]

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=20190508164506.GA21553@e107155-lin \
    --to=sudeep.holla@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=jeremy.linton@arm.com \
    --cc=john.garry@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=rjw@rjwysocki.net \
    --cc=will.deacon@arm.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).