Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752747AbbFDJGX (ORCPT ); Thu, 4 Jun 2015 05:06:23 -0400 Received: from e28smtp02.in.ibm.com ([122.248.162.2]:59654 "EHLO e28smtp02.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752115AbbFDJGQ (ORCPT ); Thu, 4 Jun 2015 05:06:16 -0400 Message-ID: <557014FC.2000209@linux.vnet.ibm.com> Date: Thu, 04 Jun 2015 14:36:04 +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-0005-0000-0000-000005B8D1FA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3831 Lines: 131 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 Sure. Will rephrase it. > >> >> +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 it can. Will check 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. Yes right. I 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? Since these Nest PMUs does not support sampling. IIUC, "perf record" interface uses the event start/stop ops. Incase of perf stat interface event add/del interface are used to enable and disable the counters. Now, when we disable or delete, we update the event counter 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/