linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jglauber@cavium.com (Jan Glauber)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for Cavium ThunderX
Date: Fri, 11 Mar 2016 11:54:24 +0100	[thread overview]
Message-ID: <20160311105423.GA4442@wintermute> (raw)
In-Reply-To: <20160212173658.GD20262@leverpostej>

On Fri, Feb 12, 2016 at 05:36:59PM +0000, Mark Rutland wrote:
> On Fri, Feb 12, 2016 at 05:55:06PM +0100, Jan Glauber wrote:

[...]

> > +int thunder_uncore_event_init(struct perf_event *event)
> > +{
> > +	struct hw_perf_event *hwc = &event->hw;
> > +	struct thunder_uncore *uncore;
> > +
> > +	if (event->attr.type != event->pmu->type)
> > +		return -ENOENT;
> > +
> > +	/* we do not support sampling */
> > +	if (is_sampling_event(event))
> > +		return -EINVAL;
> > +
> > +	/* counters do not have these bits */
> > +	if (event->attr.exclude_user	||
> > +	    event->attr.exclude_kernel	||
> > +	    event->attr.exclude_host	||
> > +	    event->attr.exclude_guest	||
> > +	    event->attr.exclude_hv	||
> > +	    event->attr.exclude_idle)
> > +		return -EINVAL;
> 
> We should _really_ make these features opt-in at the core level. It's
> crazy that each and every PMU drivers has to explicitly test and reject
> things it doesn't support.
> 

Looking at the exclude_* feature handling in pmu->event_init under
arch/ shows lots of differences. Just as an example, exclude_idle
returns sometimes -EINVAL, sometimes -EPERM while other archs
ignore it and one silently deletes the flag.

So it looks hard to me to move the exclude handling into
perf core while keeping the per-arch differences. And if we
don't and return an error on the perf_event_open syscall in a newer
kernel for an exclude bit that was previously ignored it will be a
user-space regression, right?

Looking only at the uncore drivers (plus drivers/bus/arm-cc*)
it looks like they all don't support any exclude bits but the
handling here differs also. The table shows the current behaviour,
X means the requested exclude flag is refused.

                          user  kernel  host    guest    hv     idle
---------------------------------------------------------------------
x86 uncore intel        |  X      X                      X       X
x86 uncore intel snb    |  X      X      X       X       X       X
x86 uncore intel cqm    |  X      X      X       X       X       X
x86 uncore intel cstate |  X      X      X       X       X       X
x86 uncore intel rapl   |  X      X      X       X       X       X
x86 uncore amd          |  X      X      X       X
x86 uncore amd iommu    |  X      X      X       X
x86 uncore amd ibs      |  X      X      X       X       X       X
arm bus cci             |  X      X      X       X       X       X
arm bus ccn             |  X      X                      X       X
----------------------------------------------------------------------

How about simply adding a helper function to include/linux/perf_event.h
that checks if _any_ of the exclude bits is set? We could then
simplify the check-for-any exclude flag to:

if (any_exclude_set(event))
	return -EINVAL;

What's your opinion?

Jan

---

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f5c5a3f..0eacdba0 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -849,6 +849,18 @@ static inline bool is_sampling_event(struct perf_event *event)
 	return event->attr.sample_period != 0;
 }
 
+static inline int any_exclude_set(struct perf_event *event)
+{
+	if (event->attr.exclude_user	||
+	    event->attr.exclude_kernel	||
+	    event->attr.exclude_host	||
+	    event->attr.exclude_guest	||
+	    event->attr.exclude_hv	||
+	    event->attr.exclude_idle)
+		return 1;
+	return 0;
+}
+
 /*
  * Return 1 for a software event, 0 for a hardware event
  */

  parent reply	other threads:[~2016-03-11 10:54 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 16:55 [RFC PATCH 0/7] Cavium ThunderX uncore PMU support Jan Glauber
2016-02-12 16:55 ` [RFC PATCH 1/7] arm64/perf: Basic uncore counter support for Cavium ThunderX Jan Glauber
2016-02-12 17:36   ` Mark Rutland
2016-02-13  1:47     ` David Daney
2016-02-15 11:33       ` Mark Rutland
2016-02-15 14:07     ` Jan Glauber
2016-02-15 14:27       ` Mark Rutland
2016-02-15 14:46         ` Mark Rutland
2016-02-15 15:34         ` Jan Glauber
2016-02-16  8:41     ` Jan Glauber
2016-03-11 10:54     ` Jan Glauber [this message]
2016-02-12 16:55 ` [RFC PATCH 2/7] arm64/perf: Cavium ThunderX L2C TAD uncore support Jan Glauber
2016-02-12 16:55 ` [RFC PATCH 3/7] arm64/perf: Cavium ThunderX L2C CBC " Jan Glauber
2016-02-12 16:55 ` [RFC PATCH 4/7] arm64/perf: Cavium ThunderX LMC " Jan Glauber
2016-02-12 16:55 ` [RFC PATCH 5/7] arm64/perf: Cavium ThunderX OCX LNE " Jan Glauber
2016-02-12 16:55 ` [RFC PATCH 6/7] arm64/perf: Cavium ThunderX OCX FRC " Jan Glauber
2016-02-12 16:55 ` [RFC PATCH 7/7] arm64/perf: Cavium ThunderX OCX TLK " Jan Glauber
2016-02-12 17:00 ` [RFC PATCH 0/7] Cavium ThunderX uncore PMU support Mark Rutland

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=20160311105423.GA4442@wintermute \
    --to=jglauber@cavium.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 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).