Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752592AbbFDJ2H (ORCPT ); Thu, 4 Jun 2015 05:28:07 -0400 Received: from e28smtp06.in.ibm.com ([122.248.162.6]:42756 "EHLO e28smtp06.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751685AbbFDJ2C (ORCPT ); Thu, 4 Jun 2015 05:28:02 -0400 Message-ID: <55701A13.6020304@linux.vnet.ibm.com> Date: Thu, 04 Jun 2015 14:57:47 +0530 From: Madhavan Srinivasan User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniel Axtens CC: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Stephane Eranian , Paul Mackerras , Sukadev Bhattiprolu , Anshuman Khandual Subject: Re: [PATCH v1 4/9]powerpc/powernv: Add generic nest pmu ops References: <1433260778-26497-1-git-send-email-maddy@linux.vnet.ibm.com> <1433260778-26497-5-git-send-email-maddy@linux.vnet.ibm.com> <1433289819.438.38.camel@axtens.net> In-Reply-To: <1433289819.438.38.camel@axtens.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15060409-0021-0000-0000-0000059C0BC7 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3791 Lines: 130 On Wednesday 03 June 2015 05:33 AM, Daniel Axtens wrote: > On Tue, 2015-06-02 at 21:29 +0530, Madhavan Srinivasan wrote: >> Patch adds generic nest pmu functions and format attribute. >> > I'm not sure this commit message accurately reflects the content of the > patch. At any rate, please could you: > - say what the patch adds the functions and attributes to. > - phrase your message as "Add generic ..." not "Patch adds > generic ...": see > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches#n155 > I will rephrase the commit message. >> >> +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, >> +}; > Can these structs be constified? I guess so. Will try it out. >> + >> +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 || >> + event->attr.sample_period) /* no sampling */ >> + return -EINVAL; > You test for sample period twice here. My bad. Will remove it. >> + >> + 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; >> +} >> + >> +void p8_nest_read_counter(struct perf_event *event) >> +{ >> + u64 *addr; >> + u64 data = 0; >> + >> + addr = (u64 *)event->hw.event_base; >> + data = __be64_to_cpu((uint64_t)*addr); >> + local64_set(&event->hw.prev_count, data); >> +} >> + >> +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; >> + counter_prev = local64_read(&event->hw.prev_count); >> + counter_new = __be64_to_cpu((uint64_t)*addr); >> + final_count = counter_new - counter_prev; >> + >> + local64_set(&event->hw.prev_count, counter_new); >> + local64_add(final_count, &event->count); >> +} >> + >> +void p8_nest_event_start(struct perf_event *event, int flags) >> +{ >> + event->hw.state = 0; >> + p8_nest_read_counter(event); >> +} >> + >> +void p8_nest_event_stop(struct perf_event *event, int flags) >> +{ >> + p8_nest_perf_event_update(event); >> +} >> + >> +int p8_nest_event_add(struct perf_event *event, int flags) >> +{ >> + p8_nest_event_start(event, flags); >> + return 0; >> +} >> + >> +void p8_nest_event_del(struct perf_event *event, int flags) >> +{ >> + p8_nest_event_stop(event, flags); > Is this necessary? > > Stop calls update, which I guess makes sense as it finalises the value. > But if the event is being deleted anyway, why not just do nothing here? IIUC, "perf record" will use the event start/stop interface. Incase of "perf stat" (for PMUs which does not support sampling), event add/del interface is used. Now when event is disable or deleted, event count should get updated with the delta value. >> +} >> + > Regards, > Daniel Axtens Thanks for the review Maddy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/