From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
To: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
rusty@rustcorp.com.au, Michael Ellerman <mpe@ellerman.id.au>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Anton Blanchard <anton@samba.org>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH v2 6/7]powerpc/powernv: generic nest pmu event functions
Date: Wed, 24 Jun 2015 09:22:38 +0530 [thread overview]
Message-ID: <558A2986.1030505@linux.vnet.ibm.com> (raw)
In-Reply-To: <20150623014949.GE25856@us.ibm.com>
On Tuesday 23 June 2015 07:19 AM, Sukadev Bhattiprolu wrote:
> Madhavan Srinivasan [maddy@linux.vnet.ibm.com] wrote:
> | From: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> | Subject: [PATCH v2 6/7]powerpc/powernv: generic nest pmu event functions
> |
> | Add generic format attribute and set of generic nest pmu related
> | event functions to be used by each nest pmu. Add code to register nest pmus.
> |
> | Cc: Michael Ellerman <mpe@ellerman.id.au>
> | Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> | Cc: Paul Mackerras <paulus@samba.org>
> | Cc: Anton Blanchard <anton@samba.org>
> | Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
> | Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
> | Cc: Stephane Eranian <eranian@google.com>
> | Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
> | ---
> | arch/powerpc/perf/nest-pmu.c | 109 +++++++++++++++++++++++++++++++++++++++++++
> | 1 file changed, 109 insertions(+)
> |
> | diff --git a/arch/powerpc/perf/nest-pmu.c b/arch/powerpc/perf/nest-pmu.c
> | index 8fad2d9..a662c14 100644
> | --- a/arch/powerpc/perf/nest-pmu.c
> | +++ b/arch/powerpc/perf/nest-pmu.c
> | @@ -13,6 +13,108 @@
> | static struct perchip_nest_info p8_perchip_nest_info[P8_MAX_CHIP];
> | static struct nest_pmu *per_nest_pmu_arr[P8_MAX_NEST_PMUS];
> |
> | +PMU_FORMAT_ATTR(event, "config:0-20");
> | +struct attribute *p8_nest_format_attrs[] = {
> | + &format_attr_event.attr,
> | + NULL,
> | +};
> | +
> | +struct attribute_group p8_nest_format_group = {
> | + .name = "format",
> | + .attrs = p8_nest_format_attrs,
> | +};
>
> Could this be included in previous/separate patch? That way,
> this patch could focus on just registering the nest-pmu.
Yes. Will move it.
> | +
> | +static int p8_nest_event_init(struct perf_event *event)
> | +{
> | + int chip_id;
> | +
> | + if (event->attr.type != event->pmu->type)
> | + return -ENOENT;
> | +
> | + /* Sampling not supported yet */
> | + if (event->hw.sample_period)
> | + return -EINVAL;
> | +
> | + /* unsupported modes and filters */
> | + if (event->attr.exclude_user ||
> | + event->attr.exclude_kernel ||
> | + event->attr.exclude_hv ||
> | + event->attr.exclude_idle ||
> | + event->attr.exclude_host ||
> | + event->attr.exclude_guest)
> | + return -EINVAL;
> | +
> | + if (event->cpu < 0)
> | + return -EINVAL;
> | +
> | + chip_id = topology_physical_package_id(event->cpu);
> | + event->hw.event_base = event->attr.config +
> | + p8_perchip_nest_info[chip_id].vbase;
> | +
> | + return 0;
> | +}
> | +
> | +static void p8_nest_read_counter(struct perf_event *event)
> | +{
> | + u64 *addr;
> |
>
> Define as uint64_t so we can eliminate one cast below? Would also
> be consistent with p8_nest_perf_event_update().
Yes make sense.
> |
> | + u64 data = 0;
> | +
> | + addr = (u64 *)event->hw.event_base;
> | + data = __be64_to_cpu((uint64_t)*addr);
> | + local64_set(&event->hw.prev_count, data);
> | +}
> | +
> | +static void p8_nest_perf_event_update(struct perf_event *event)
> | +{
> | + u64 counter_prev, counter_new, final_count;
> | + uint64_t *addr;
> | +
> | + addr = (u64 *)event->hw.event_base;
>
> uint64_t *?
My bad. will change it.
> | + counter_prev = local64_read(&event->hw.prev_count);
> | + counter_new = __be64_to_cpu((uint64_t)*addr);
>
> Redundant cast? addr is already uint64_t *?
Nice catch. Will remove it.
> | + final_count = counter_new - counter_prev;
> | +
> | + local64_set(&event->hw.prev_count, counter_new);
> | + local64_add(final_count, &event->count);
> | +}
> | +
> | +static void p8_nest_event_start(struct perf_event *event, int flags)
> | +{
>
> Check PERF_EF_RELOAD before reloading?
>
> | + event->hw.state = 0;
> | + p8_nest_read_counter(event);
> | +}
> | +
> | +static void p8_nest_event_stop(struct perf_event *event, int flags)
> | +{
>
> Check PERF_EF_UPDATE when stopping?
>
> | + p8_nest_perf_event_update(event);
> | +}
> | +
> | +static int p8_nest_event_add(struct perf_event *event, int flags)
> | +{
>
> Check PERF_EF_START flags before starting the counter on an ->add()?
Will add the flags.
> | + p8_nest_event_start(event, flags);
> | + return 0;
> | +}
> | +
> | +/*
> | + * Populate pmu ops in the structure
> | + */
> | +static int update_pmu_ops(struct nest_pmu *pmu)
> | +{
> | + if (!pmu)
> | + return -EINVAL;
> | +
> | + pmu->pmu.task_ctx_nr = perf_invalid_context;
> | + pmu->pmu.event_init = p8_nest_event_init;
> | + pmu->pmu.add = p8_nest_event_add;
> | + pmu->pmu.del = p8_nest_event_stop;
> | + pmu->pmu.start = p8_nest_event_start;
> | + pmu->pmu.stop = p8_nest_event_stop;
> | + pmu->pmu.read = p8_nest_perf_event_update;
> | + pmu->pmu.attr_groups = pmu->attr_groups;
> | +
> | + return 0;
> | +}
> | +
> | /*
> | * Populate event name and string in attribute
> | */
> | @@ -106,6 +208,7 @@ static int nest_pmu_create(struct device_node *dev, int pmu_index)
> | /* Save the name to register the PMU with it */
> | sprintf(buf, "Nest_%s", (char *)pp->value);
> | pmu_ptr->pmu.name = (char *)buf;
> | + pmu_ptr->attr_groups[1] = &p8_nest_format_group;
> | }
> |
> | /* Skip these, we dont need it */
> | @@ -179,6 +282,12 @@ static int nest_pmu_create(struct device_node *dev, int pmu_index)
> | (struct ppc64_nest_ima_events *)p8_events_arr,
> | idx, pmu_ptr);
> |
> | + update_pmu_ops(pmu_ptr);
> | +
> | + /* Register the pmu */
> | + perf_pmu_register(&pmu_ptr->pmu, pmu_ptr->pmu.name, -1);
>
> There is a small chance that perf_pmu_register() can fail.
Sure. Will have a check for the return value.
Thanks for review
Maddy
> | + printk(KERN_INFO "Nest PMU %s Registered\n", pmu_ptr->pmu.name);
> | +
> | return 0;
> | }
> |
> | --
> | 1.9.1
> |
next prev parent reply other threads:[~2015-06-24 3:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 5:17 [PATCH v2 0/7]powerpc/powernv: Nest Instrumentation support Madhavan Srinivasan
2015-06-11 5:17 ` [PATCH v2 1/7]powerpc/powernv: Data structure and macros definition Madhavan Srinivasan
2015-06-11 5:17 ` [PATCH v2 2/7]powerpc/powernv: Add OPAL support for Nest PMU Madhavan Srinivasan
2015-06-11 5:17 ` [PATCH v2 3/7]powerpc/powernv: Nest PMU detection and device tree parser Madhavan Srinivasan
2015-06-11 5:17 ` [PATCH v2 4/7]powerpc/powernv: detect supported nest pmus and its events Madhavan Srinivasan
2015-06-11 5:17 ` [PATCH v2 5/7]powerpc/powernv: add event attribute and group to nest pmu Madhavan Srinivasan
2015-06-11 5:17 ` [PATCH v2 6/7]powerpc/powernv: generic nest pmu event functions Madhavan Srinivasan
2015-06-23 1:49 ` Sukadev Bhattiprolu
2015-06-23 1:49 ` Sukadev Bhattiprolu
2015-06-24 3:52 ` Madhavan Srinivasan [this message]
2015-06-11 5:17 ` [PATCH v2 7/7]powerpc/powernv: nest pmu cpumask and cpu hotplug support Madhavan Srinivasan
2015-06-16 6:28 ` Preeti U Murthy
2015-06-22 9:15 ` Madhavan Srinivasan
2015-06-22 9:15 ` Madhavan Srinivasan
2015-06-24 6:46 ` Madhavan Srinivasan
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=558A2986.1030505@linux.vnet.ibm.com \
--to=maddy@linux.vnet.ibm.com \
--cc=anton@samba.org \
--cc=benh@kernel.crashing.org \
--cc=eranian@google.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=rusty@rustcorp.com.au \
--cc=sukadev@linux.vnet.ibm.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 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.