All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 3/3] perf tool: arm-ccn: add a supplemental strerror function
Date: Tue, 24 Oct 2017 14:35:19 +0100	[thread overview]
Message-ID: <20171024133518.GA13445@arm.com> (raw)
In-Reply-To: <20171024030415.9baa5157e506892a757bf8c7@arm.com>

On Tue, Oct 24, 2017 at 03:04:15AM -0500, Kim Phillips wrote:
> Use the Arm CCN driver as an example of how to try to improve
> upon its existing dmesg error output, and duplicate error string
> generation logic in the perf tool.

[...]

> Comments?  Is this really that much better than the existing dmesg that
> the user is already being pointed to by the perf tool?

Having never used the CCN PMU, I can't speak to the usefulness of this
change, but I can say that I think this needs to be PMU-specific rather than
arch-specific. The CCN driver can, for example, be built for 32-bit ARM
systems but the directory structure here doesn't reflect that.

>  tools/perf/arch/arm64/util/Build   |  1 +
>  tools/perf/arch/arm64/util/evsel.c | 53 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 54 insertions(+)
>  create mode 100644 tools/perf/arch/arm64/util/evsel.c
> 
> diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
> index b1ab72d2a42e..8dee4aa31a68 100644
> --- a/tools/perf/arch/arm64/util/Build
> +++ b/tools/perf/arch/arm64/util/Build
> @@ -1,4 +1,5 @@
>  libperf-y += header.o
> +libperf-y     += evsel.o
>  libperf-$(CONFIG_DWARF)     += dwarf-regs.o
>  libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
>  
> diff --git a/tools/perf/arch/arm64/util/evsel.c b/tools/perf/arch/arm64/util/evsel.c
> new file mode 100644
> index 000000000000..cb9ddd6523e3
> --- /dev/null
> +++ b/tools/perf/arch/arm64/util/evsel.c
> @@ -0,0 +1,53 @@
> +#include <string.h>
> +
> +#include <linux/perf_event.h>
> +#include <linux/err.h>
> +
> +#include "../../util/evsel.h"
> +
> +#include "evsel.h"
> +
> +static int ccn_strerror(struct perf_evsel *evsel,
> +			struct target *target __maybe_unused,
> +			int err, char *msg, size_t size)
> +{
> +	const char *evname = perf_evsel__name(evsel);
> +	struct perf_event_attr *attr = &evsel->attr;
> +
> +	switch (err) {
> +	case EOPNOTSUPP:
> +		if (attr->sample_period)
> +			return scnprintf(msg, size, "%s: Sampling not supported, try 'perf stat'\n", evname);

... and then the existing code prints:

	"PMU Hardware doesn't support sampling/overflow-interrupts."

so why do we need both?

> +		if (target__has_task(target))
> +			return scnprintf(msg, size, "%s: Can't provide per-task data!\n", evname);

Isn't this the case for all uncore PMUs? If so, could we predicate this
additionally on evsel->system_wide and print this in the shared error
handler?

> +		break;
> +	case EINVAL:
> +		if ((attr->sample_type & PERF_SAMPLE_BRANCH_STACK) ||
> +			attr->exclude_user ||
> +			attr->exclude_kernel || attr->exclude_hv ||
> +			attr->exclude_idle || attr->exclude_host ||
> +			attr->exclude_guest)
> +			return scnprintf(msg, size, "%s: Can't exclude execution levels!\n", evname);

A better way to do this might be to identify some common failure modes,
e.g. unable to support some of the exclude_* fields in perf_event_attr,
then have an optional per-PMU callback which returns a bool to say
whether or not the error is because of that.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Kim Phillips <kim.phillips@arm.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	linux-arm-kernel@lists.infradead.org, marc.zyngier@arm.com,
	mark.rutland@arm.com, tglx@linutronix.de, peterz@infradead.org,
	alexander.shishkin@linux.intel.com, robh@kernel.org,
	suzuki.poulose@arm.com, pawel.moll@arm.com,
	mathieu.poirier@linaro.org, mingo@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC 3/3] perf tool: arm-ccn: add a supplemental strerror function
Date: Tue, 24 Oct 2017 14:35:19 +0100	[thread overview]
Message-ID: <20171024133518.GA13445@arm.com> (raw)
In-Reply-To: <20171024030415.9baa5157e506892a757bf8c7@arm.com>

On Tue, Oct 24, 2017 at 03:04:15AM -0500, Kim Phillips wrote:
> Use the Arm CCN driver as an example of how to try to improve
> upon its existing dmesg error output, and duplicate error string
> generation logic in the perf tool.

[...]

> Comments?  Is this really that much better than the existing dmesg that
> the user is already being pointed to by the perf tool?

Having never used the CCN PMU, I can't speak to the usefulness of this
change, but I can say that I think this needs to be PMU-specific rather than
arch-specific. The CCN driver can, for example, be built for 32-bit ARM
systems but the directory structure here doesn't reflect that.

>  tools/perf/arch/arm64/util/Build   |  1 +
>  tools/perf/arch/arm64/util/evsel.c | 53 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 54 insertions(+)
>  create mode 100644 tools/perf/arch/arm64/util/evsel.c
> 
> diff --git a/tools/perf/arch/arm64/util/Build b/tools/perf/arch/arm64/util/Build
> index b1ab72d2a42e..8dee4aa31a68 100644
> --- a/tools/perf/arch/arm64/util/Build
> +++ b/tools/perf/arch/arm64/util/Build
> @@ -1,4 +1,5 @@
>  libperf-y += header.o
> +libperf-y     += evsel.o
>  libperf-$(CONFIG_DWARF)     += dwarf-regs.o
>  libperf-$(CONFIG_LOCAL_LIBUNWIND) += unwind-libunwind.o
>  
> diff --git a/tools/perf/arch/arm64/util/evsel.c b/tools/perf/arch/arm64/util/evsel.c
> new file mode 100644
> index 000000000000..cb9ddd6523e3
> --- /dev/null
> +++ b/tools/perf/arch/arm64/util/evsel.c
> @@ -0,0 +1,53 @@
> +#include <string.h>
> +
> +#include <linux/perf_event.h>
> +#include <linux/err.h>
> +
> +#include "../../util/evsel.h"
> +
> +#include "evsel.h"
> +
> +static int ccn_strerror(struct perf_evsel *evsel,
> +			struct target *target __maybe_unused,
> +			int err, char *msg, size_t size)
> +{
> +	const char *evname = perf_evsel__name(evsel);
> +	struct perf_event_attr *attr = &evsel->attr;
> +
> +	switch (err) {
> +	case EOPNOTSUPP:
> +		if (attr->sample_period)
> +			return scnprintf(msg, size, "%s: Sampling not supported, try 'perf stat'\n", evname);

... and then the existing code prints:

	"PMU Hardware doesn't support sampling/overflow-interrupts."

so why do we need both?

> +		if (target__has_task(target))
> +			return scnprintf(msg, size, "%s: Can't provide per-task data!\n", evname);

Isn't this the case for all uncore PMUs? If so, could we predicate this
additionally on evsel->system_wide and print this in the shared error
handler?

> +		break;
> +	case EINVAL:
> +		if ((attr->sample_type & PERF_SAMPLE_BRANCH_STACK) ||
> +			attr->exclude_user ||
> +			attr->exclude_kernel || attr->exclude_hv ||
> +			attr->exclude_idle || attr->exclude_host ||
> +			attr->exclude_guest)
> +			return scnprintf(msg, size, "%s: Can't exclude execution levels!\n", evname);

A better way to do this might be to identify some common failure modes,
e.g. unable to support some of the exclude_* fields in perf_event_attr,
then have an optional per-PMU callback which returns a bool to say
whether or not the error is because of that.

Will

  reply	other threads:[~2017-10-24 13:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-24  8:04 [RFC 3/3] perf tool: arm-ccn: add a supplemental strerror function Kim Phillips
2017-10-24 13:35 ` Will Deacon [this message]
2017-10-24 13:35   ` Will Deacon
2017-10-25  1:05   ` Kim Phillips
2017-10-25  1:05     ` Kim Phillips

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=20171024133518.GA13445@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.