From: jan.glauber@caviumnetworks.com (Jan Glauber)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters
Date: Wed, 26 Jul 2017 13:19:46 +0200 [thread overview]
Message-ID: <20170726111946.GA6273@hc> (raw)
In-Reply-To: <72145781-e9ec-036f-f752-b4756fef08ee@arm.com>
On Tue, Jul 25, 2017 at 04:39:18PM +0100, Suzuki K Poulose wrote:
> On 25/07/17 16:04, 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>
> >---
> > drivers/perf/Kconfig | 8 +
> > drivers/perf/Makefile | 1 +
> > drivers/perf/cavium_pmu.c | 424 +++++++++++++++++++++++++++++++++++++++++++++
> > include/linux/cpuhotplug.h | 1 +
> > 4 files changed, 434 insertions(+)
> > create mode 100644 drivers/perf/cavium_pmu.c
> >
> >diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
> >index e5197ff..a46c3f0 100644
> >--- a/drivers/perf/Kconfig
> >+++ b/drivers/perf/Kconfig
> >@@ -43,4 +43,12 @@ config XGENE_PMU
> > help
> > Say y if you want to use APM X-Gene SoC performance monitors.
> >
> >+config CAVIUM_PMU
> >+ bool "Cavium SOC PMU"
>
> Is there any specific reason why this can't be built as a module ?
Yes. I don't know how to load the module automatically. I can't make it
a pci driver as the EDAC driver "owns" the device (and having two
drivers for one device wont work as far as I know). I tried to hook
into the EDAC driver but the EDAC maintainer was not overly welcoming
that approach.
And while it would be possible to have it a s a module I think it is of
no use if it requires manualy loading. But maybe there is a simple
solution I'm missing here?
>
> >+#define to_pmu_dev(x) container_of((x), struct cvm_pmu_dev, pmu)
> >+
> >+static int cvm_pmu_event_init(struct perf_event *event)
> >+{
> >+ struct hw_perf_event *hwc = &event->hw;
> >+ struct cvm_pmu_dev *pmu_dev;
> >+ struct perf_event *sibling;
> >+
> >+ if (event->attr.type != event->pmu->type)
> >+ return -ENOENT;
> >+
> >+ /* we do not support sampling */
> >+ if (is_sampling_event(event))
> >+ return -EINVAL;
> >+
> >+ /* PMU counters do not support any 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;
> >+
> >+ pmu_dev = to_pmu_dev(event->pmu);
> >+ if (!pmu_dev->event_valid(event->attr.config))
> >+ return -EINVAL;
> >+
> >+ /*
> >+ * Forbid groups containing mixed PMUs, software events are acceptable.
> >+ */
> >+ if (event->group_leader->pmu != event->pmu &&
> >+ !is_software_event(event->group_leader))
> >+ return -EINVAL;
> >+
> >+ list_for_each_entry(sibling, &event->group_leader->sibling_list,
> >+ group_entry)
> >+ if (sibling->pmu != event->pmu &&
> >+ !is_software_event(sibling))
> >+ return -EINVAL;
>
> Do we also need to check if the events in the same group can be scheduled
> at once ? i.e, there is enough resources to schedule the requested events from
> the group.
>
Not sure what you mean, do I need to check for programmable counters
that no more counters are programmed than available?
> >+
> >+ hwc->config = event->attr.config;
> >+ hwc->idx = -1;
> >+ return 0;
> >+}
> >+
> ...
>
> >+static int cvm_pmu_add(struct perf_event *event, int flags, u64 config_base,
> >+ u64 event_base)
> >+{
> >+ struct cvm_pmu_dev *pmu_dev = to_pmu_dev(event->pmu);
> >+ struct hw_perf_event *hwc = &event->hw;
> >+
> >+ if (!cmpxchg(&pmu_dev->events[hwc->config], NULL, event))
> >+ hwc->idx = hwc->config;
> >+
> >+ if (hwc->idx == -1)
> >+ return -EBUSY;
> >+
> >+ hwc->config_base = config_base;
> >+ hwc->event_base = event_base;
> >+ hwc->state = PERF_HES_UPTODATE | PERF_HES_STOPPED;
> >+
> >+ if (flags & PERF_EF_START)
> >+ pmu_dev->pmu.start(event, PERF_EF_RELOAD);
> >+
> >+ return 0;
> >+}
> >+
> >+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;
>
> I couldn't see why hwc->config wouldn't give us the index where we installed
> the event in pmu_dev->events. What am I missing ?
Did you see the comment above? It is not yet needed but will be when I
add support for programmable counters. If it is still confusing I can
also remove that for now and add it back later when it is needed.
> >+static int __init cvm_pmu_init(void)
> >+{
> >+ unsigned long implementor = read_cpuid_implementor();
> >+ unsigned int vendor_id = PCI_VENDOR_ID_CAVIUM;
> >+ struct pci_dev *pdev = NULL;
> >+ int rc;
> >+
> >+ if (implementor != ARM_CPU_IMP_CAVIUM)
> >+ return -ENODEV;
>
> As I mentioned in the beginning, it would be better to modularize it right
> from the start, when we can, than coming back to this at a later point in time.
>
> Btw, perf_event_update_userpage() is being exported for use from module.
> See [0].
>
> [0] http://lists.infradead.org/pipermail/linux-arm-kernel/2017-July/520682.html
Nice, I think I proposed something similar :)
thanks,
Jan
> Cheers
>
> Suzuki
next prev parent reply other threads:[~2017-07-26 11:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-25 15:04 [PATCH v8 0/3] Cavium ARM64 uncore PMU support Jan Glauber
2017-07-25 15:04 ` [PATCH v8 1/3] perf: cavium: Support memory controller PMU counters Jan Glauber
2017-07-25 15:39 ` Suzuki K Poulose
2017-07-26 11:19 ` Jan Glauber [this message]
2017-07-26 12:47 ` Suzuki K Poulose
2017-07-26 13:10 ` Jan Glauber
2017-07-26 14:35 ` Suzuki K Poulose
2017-07-26 14:55 ` Borislav Petkov
2017-07-26 15:13 ` Jan Glauber
2017-07-26 15:17 ` Suzuki K Poulose
2017-07-26 15:28 ` Borislav Petkov
2017-07-26 15:46 ` Jan Glauber
2017-07-26 16:25 ` Jonathan Cameron
2017-07-26 16:40 ` Jan Glauber
2017-07-26 15:35 ` Borislav Petkov
2017-07-26 15:45 ` Jan Glauber
2017-07-26 15:55 ` Borislav Petkov
2017-07-26 16:19 ` Greg KH
2017-07-26 16:30 ` Borislav Petkov
2017-07-26 17:33 ` Greg KH
2017-07-26 20:02 ` David Daney
2017-07-26 20:08 ` Greg KH
2017-07-26 21:02 ` David Daney
2017-07-27 2:29 ` Greg KH
2017-07-27 17:29 ` David Daney
2017-07-28 1:11 ` Greg KH
2017-07-28 7:23 ` Borislav Petkov
2017-07-27 5:11 ` Borislav Petkov
2017-07-27 9:08 ` Jan Glauber
2017-07-27 13:15 ` Borislav Petkov
2017-07-28 23:12 ` Greg KH
2017-08-08 13:25 ` Will Deacon
2017-08-15 9:13 ` Jan Glauber
2017-08-07 9:37 ` Suzuki K Poulose
2017-07-25 15:56 ` Jonathan Cameron
2017-07-25 15:04 ` [PATCH v8 2/3] perf: cavium: Support transmit-link " Jan Glauber
2017-07-25 15:04 ` [PATCH v8 3/3] perf: cavium: Add Documentation 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=20170726111946.GA6273@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 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).