All of lore.kernel.org
 help / color / mirror / Atom feed
From: jan.glauber@caviumnetworks.com (Jan Glauber)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v9 5/7] perf: cavium: Support memory controller PMU counters
Date: Thu, 31 Aug 2017 13:35:08 +0200	[thread overview]
Message-ID: <20170831113508.GE15906@hc> (raw)
In-Reply-To: <09997d9f-0003-0eb0-63d1-9b31e26e2229@arm.com>

On Wed, Aug 30, 2017 at 11:03:00AM +0100, Suzuki K Poulose wrote:
> On 29/08/17 14:12, Jan Glauber wrote:
> >Add support for the PMU counters on Cavium SOC memory controllers.
> >
> >This patch also adds generic functions to allow supporting more
> >devices with PMU counters.
> >
> >Properties of the LMC PMU counters:
> >- not stoppable
> >- fixed purpose
> >- read-only
> >- one PCI device per memory controller
> >
> >Signed-off-by: Jan Glauber <jglauber@cavium.com>
> 
> Jan,
> 
> Some minor comments below.
> 
> >+static void cvm_pmu_del(struct perf_event *event, int flags)
> >+{
> >+	struct cvm_pmu_dev *pmu_dev = to_pmu_dev(event->pmu);
> >+	struct hw_perf_event *hwc = &event->hw;
> >+	int i;
> >+
> >+	event->pmu->stop(event, PERF_EF_UPDATE);
> >+
> >+	/*
> >+	 * For programmable counters we need to check where we installed it.
> >+	 * To keep this function generic always test the more complicated
> >+	 * case (free running counters won't need the loop).
> >+	 */
> >+	for (i = 0; i < pmu_dev->num_counters; i++)
> >+		if (cmpxchg(&pmu_dev->events[i], event, NULL) == event)
> >+			break;
> 
> Does this mean, it is the only way to map any given event (for programmable counters)
> to a hardware counter ? What do we store in hwc->idx ? We have 2 additional
> struct hw_perf_event_extra fields. We should be able to use one field to map it
> back to the counter, isn't it ?

Hmm, I might be able to use hwc-idx directly instead of the loop, will
check that.

> >+
> >+	perf_event_update_userpage(event);
> >+	hwc->idx = -1;
> >+}
> >+
> 
> ...
> 
> >+/* LMC events */
> >+#define LMC_EVENT_IFB_CNT		0x1d0
> >+#define LMC_EVENT_OPS_CNT		0x1d8
> >+#define LMC_EVENT_DCLK_CNT		0x1e0
> >+#define LMC_EVENT_BANK_CONFLICT1	0x360
> >+#define LMC_EVENT_BANK_CONFLICT2	0x368
> >+
> >+#define CVM_PMU_LMC_EVENT_ATTR(_name, _id)						\
> >+	&((struct perf_pmu_events_attr[]) {						\
> >+		{									\
> >+			__ATTR(_name, S_IRUGO, cvm_pmu_event_sysfs_show, NULL),		\
> >+			_id,								\
> >+			"lmc_event=" __stringify(_id),					\
> >+		}									\
> >+	})[0].attr.attr
> >+
> >+/* map counter numbers to register offsets */
> >+static int lmc_events[] = {
> >+	LMC_EVENT_IFB_CNT,
> >+	LMC_EVENT_OPS_CNT,
> >+	LMC_EVENT_DCLK_CNT,
> >+	LMC_EVENT_BANK_CONFLICT1,
> >+	LMC_EVENT_BANK_CONFLICT2,
> >+};
> >+
> >+static int cvm_pmu_lmc_add(struct perf_event *event, int flags)
> >+{
> >+	struct hw_perf_event *hwc = &event->hw;
> >+
> >+	return cvm_pmu_add(event, flags, LMC_CONFIG_OFFSET,
> >+			   lmc_events[hwc->config]);
> >+}
> >+
> 
> Is there any reason why we can't use the LMC event code directly
> here, avoiding the mapping altogether ?

I wanted to avoid exposing the raw numbers (0x1d0 - 0x368) here.

thanks,
Jan

> >+PMU_FORMAT_ATTR(lmc_event, "config:0-2");
> >+
> >+static struct attribute *cvm_pmu_lmc_format_attr[] = {
> >+	&format_attr_lmc_event.attr,
> >+	NULL,
> >+};
> >+
> >+static struct attribute_group cvm_pmu_lmc_format_group = {
> >+	.name = "format",
> >+	.attrs = cvm_pmu_lmc_format_attr,
> >+};
> >+
> >+static struct attribute *cvm_pmu_lmc_events_attr[] = {
> >+	CVM_PMU_LMC_EVENT_ATTR(ifb_cnt,		0),
> >+	CVM_PMU_LMC_EVENT_ATTR(ops_cnt,		1),
> >+	CVM_PMU_LMC_EVENT_ATTR(dclk_cnt,	2),
> >+	CVM_PMU_LMC_EVENT_ATTR(bank_conflict1,	3),
> >+	CVM_PMU_LMC_EVENT_ATTR(bank_conflict2,	4),
> >+	NULL,
> >+};

WARNING: multiple messages have this Message-ID (diff)
From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Suzuki K Poulose <Suzuki.Poulose@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Borislav Petkov <bp@alien8.de>,
	David Daney <david.daney@cavium.com>
Subject: Re: [RFC PATCH v9 5/7] perf: cavium: Support memory controller PMU counters
Date: Thu, 31 Aug 2017 13:35:08 +0200	[thread overview]
Message-ID: <20170831113508.GE15906@hc> (raw)
In-Reply-To: <09997d9f-0003-0eb0-63d1-9b31e26e2229@arm.com>

On Wed, Aug 30, 2017 at 11:03:00AM +0100, Suzuki K Poulose wrote:
> On 29/08/17 14:12, Jan Glauber wrote:
> >Add support for the PMU counters on Cavium SOC memory controllers.
> >
> >This patch also adds generic functions to allow supporting more
> >devices with PMU counters.
> >
> >Properties of the LMC PMU counters:
> >- not stoppable
> >- fixed purpose
> >- read-only
> >- one PCI device per memory controller
> >
> >Signed-off-by: Jan Glauber <jglauber@cavium.com>
> 
> Jan,
> 
> Some minor comments below.
> 
> >+static void cvm_pmu_del(struct perf_event *event, int flags)
> >+{
> >+	struct cvm_pmu_dev *pmu_dev = to_pmu_dev(event->pmu);
> >+	struct hw_perf_event *hwc = &event->hw;
> >+	int i;
> >+
> >+	event->pmu->stop(event, PERF_EF_UPDATE);
> >+
> >+	/*
> >+	 * For programmable counters we need to check where we installed it.
> >+	 * To keep this function generic always test the more complicated
> >+	 * case (free running counters won't need the loop).
> >+	 */
> >+	for (i = 0; i < pmu_dev->num_counters; i++)
> >+		if (cmpxchg(&pmu_dev->events[i], event, NULL) == event)
> >+			break;
> 
> Does this mean, it is the only way to map any given event (for programmable counters)
> to a hardware counter ? What do we store in hwc->idx ? We have 2 additional
> struct hw_perf_event_extra fields. We should be able to use one field to map it
> back to the counter, isn't it ?

Hmm, I might be able to use hwc-idx directly instead of the loop, will
check that.

> >+
> >+	perf_event_update_userpage(event);
> >+	hwc->idx = -1;
> >+}
> >+
> 
> ...
> 
> >+/* LMC events */
> >+#define LMC_EVENT_IFB_CNT		0x1d0
> >+#define LMC_EVENT_OPS_CNT		0x1d8
> >+#define LMC_EVENT_DCLK_CNT		0x1e0
> >+#define LMC_EVENT_BANK_CONFLICT1	0x360
> >+#define LMC_EVENT_BANK_CONFLICT2	0x368
> >+
> >+#define CVM_PMU_LMC_EVENT_ATTR(_name, _id)						\
> >+	&((struct perf_pmu_events_attr[]) {						\
> >+		{									\
> >+			__ATTR(_name, S_IRUGO, cvm_pmu_event_sysfs_show, NULL),		\
> >+			_id,								\
> >+			"lmc_event=" __stringify(_id),					\
> >+		}									\
> >+	})[0].attr.attr
> >+
> >+/* map counter numbers to register offsets */
> >+static int lmc_events[] = {
> >+	LMC_EVENT_IFB_CNT,
> >+	LMC_EVENT_OPS_CNT,
> >+	LMC_EVENT_DCLK_CNT,
> >+	LMC_EVENT_BANK_CONFLICT1,
> >+	LMC_EVENT_BANK_CONFLICT2,
> >+};
> >+
> >+static int cvm_pmu_lmc_add(struct perf_event *event, int flags)
> >+{
> >+	struct hw_perf_event *hwc = &event->hw;
> >+
> >+	return cvm_pmu_add(event, flags, LMC_CONFIG_OFFSET,
> >+			   lmc_events[hwc->config]);
> >+}
> >+
> 
> Is there any reason why we can't use the LMC event code directly
> here, avoiding the mapping altogether ?

I wanted to avoid exposing the raw numbers (0x1d0 - 0x368) here.

thanks,
Jan

> >+PMU_FORMAT_ATTR(lmc_event, "config:0-2");
> >+
> >+static struct attribute *cvm_pmu_lmc_format_attr[] = {
> >+	&format_attr_lmc_event.attr,
> >+	NULL,
> >+};
> >+
> >+static struct attribute_group cvm_pmu_lmc_format_group = {
> >+	.name = "format",
> >+	.attrs = cvm_pmu_lmc_format_attr,
> >+};
> >+
> >+static struct attribute *cvm_pmu_lmc_events_attr[] = {
> >+	CVM_PMU_LMC_EVENT_ATTR(ifb_cnt,		0),
> >+	CVM_PMU_LMC_EVENT_ATTR(ops_cnt,		1),
> >+	CVM_PMU_LMC_EVENT_ATTR(dclk_cnt,	2),
> >+	CVM_PMU_LMC_EVENT_ATTR(bank_conflict1,	3),
> >+	CVM_PMU_LMC_EVENT_ATTR(bank_conflict2,	4),
> >+	NULL,
> >+};

  reply	other threads:[~2017-08-31 11:35 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-29 13:12 [RFC PATCH v9 0/7] Cavium ARM64 uncore PMU support Jan Glauber
2017-08-29 13:12 ` Jan Glauber
2017-08-29 13:12 ` [RFC PATCH v9 1/7] edac: thunderx: Remove suspend/resume support Jan Glauber
2017-08-29 13:12   ` Jan Glauber
2017-08-30 17:54   ` Borislav Petkov
2017-08-30 17:54     ` Borislav Petkov
2017-08-31  8:46     ` Jan Glauber
2017-08-31  8:46       ` Jan Glauber
2017-08-29 13:12 ` [RFC PATCH v9 2/7] edac, soc: thunderx: Add wrapper for EDAC LMC PCI device Jan Glauber
2017-08-29 13:12   ` [RFC PATCH v9 2/7] edac,soc: " Jan Glauber
2017-08-29 13:12 ` [RFC PATCH v9 3/7] edac, soc: thunderx: Add wrapper for EDAC OCX " Jan Glauber
2017-08-29 13:12   ` [RFC PATCH v9 3/7] edac,soc: " Jan Glauber
2017-08-29 13:12 ` [RFC PATCH v9 4/7] perf: export perf_event_update_userpage() Jan Glauber
2017-08-29 13:12   ` Jan Glauber
2017-08-29 13:12 ` [RFC PATCH v9 5/7] perf: cavium: Support memory controller PMU counters Jan Glauber
2017-08-29 13:12   ` Jan Glauber
2017-08-30  2:54   ` Zhangshaokun
2017-08-30  2:54     ` Zhangshaokun
2017-08-31  9:57     ` Jan Glauber
2017-08-31  9:57       ` Jan Glauber
2017-08-31 10:31       ` Mark Rutland
2017-08-31 10:31         ` Mark Rutland
2017-08-31 11:13         ` Jan Glauber
2017-08-31 11:13           ` Jan Glauber
2017-08-31 11:18         ` Jan Glauber
2017-08-31 11:18           ` Jan Glauber
2017-08-30 10:03   ` Suzuki K Poulose
2017-08-30 10:03     ` Suzuki K Poulose
2017-08-31 11:35     ` Jan Glauber [this message]
2017-08-31 11:35       ` Jan Glauber
2017-08-31 13:26       ` Suzuki K Poulose
2017-08-31 13:26         ` Suzuki K Poulose
2017-08-31 15:27         ` Jan Glauber
2017-08-31 15:27           ` Jan Glauber
2017-08-29 13:12 ` [RFC PATCH v9 6/7] perf: cavium: Support transmit-link " Jan Glauber
2017-08-29 13:12   ` Jan Glauber
2017-08-29 13:12 ` [RFC PATCH v9 7/7] perf: cavium: Add Documentation Jan Glauber
2017-08-29 13:12   ` Jan Glauber
2017-08-31 11:38 ` [RFC PATCH v9 0/7] Cavium ARM64 uncore PMU support Jan Glauber
2017-08-31 11:38   ` Jan Glauber

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=20170831113508.GE15906@hc \
    --to=jan.glauber@caviumnetworks.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.