From: Ian Rogers <irogers@google.com> To: John Garry <john.garry@huawei.com> Cc: Jiri Olsa <jolsa@redhat.com>, Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@redhat.com>, Arnaldo Carvalho de Melo <acme@kernel.org>, Mark Rutland <mark.rutland@arm.com>, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Namhyung Kim <namhyung@kernel.org>, will@kernel.org, Andi Kleen <ak@linux.intel.com>, linuxarm@huawei.com, LKML <linux-kernel@vger.kernel.org>, qiangqing.zhang@nxp.com, robin.murphy@arm.com, zhangshaokun@hisilicon.com, Linux ARM <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH RFC v3 02/12] perf jevents: Add support for system events tables Date: Mon, 11 May 2020 09:21:00 -0700 [thread overview] Message-ID: <CAP-5=fWHipkL6Uq1vMaz-51ETPWajofDXd6RTBMr00pcyooo_g@mail.gmail.com> (raw) In-Reply-To: <9f4ea413-325f-98b4-eb4c-e47aead4f455@huawei.com> On Mon, May 11, 2020 at 8:03 AM John Garry <john.garry@huawei.com> wrote: > > On 11/05/2020 12:01, Jiri Olsa wrote: > > On Thu, May 07, 2020 at 07:57:41PM +0800, John Garry wrote: > > > > SNIP > > > >> + &sys_event_tables); > >> + } > >> + > >> print_events_table_prefix(eventsfp, tblname); > >> return 0; > >> } > >> @@ -1180,7 +1253,6 @@ int main(int argc, char *argv[]) > >> } else if (rc < 0) { > >> /* Make build fail */ > >> fclose(eventsfp); > >> - free_arch_std_events(); > >> ret = 1; > >> goto out_free_mapfile; > >> } else if (rc) { > >> @@ -1206,27 +1278,31 @@ int main(int argc, char *argv[]) > >> if (close_table) > >> print_events_table_suffix(eventsfp); > >> > >> - if (!mapfile) { > >> - pr_info("%s: No CPU->JSON mapping?\n", prog); > >> - goto empty_map; > >> + if (mapfile) { > >> + if (process_mapfile(eventsfp, mapfile)) { > >> + pr_err("%s: Error processing mapfile %s\n", prog, > >> + mapfile); > >> + /* Make build fail */ > >> + fclose(eventsfp); > >> + ret = 1; > >> + } > >> + } else { > >> + pr_err("%s: No CPU->JSON mapping?\n", prog); > > > > shouldn't we jump to empty_map in here? there still needs to be a > > mapfile, right? > > In theory we could only support sys events :) > > But I'll now make this a (empty map) failure case. And I think that > another error case handling needs fixing in my patch. > > > As for this: > > + fprintf(outfp, "struct pmu_sys_events pmu_sys_event_tables[] = {"); > >> + > >> + list_for_each_entry(sys_event_table, &sys_event_tables, list) { > >> + fprintf(outfp, "\n\t{\n\t\t.table = %s,\n\t},", > >> + sys_event_table->name); > >> + } > >> + fprintf(outfp, "\n\t{\n\t\t.table = 0\n\t},"); > > > > this will add extra tabs: > > > > { > > .table = 0 > > }, > > > > while the rest of the file starts items without any indent > > > > I'll ensure the indent is the same. > > BTW, is there anything to be said for removing the empty map feature > (and always breaking the perf build instead)? I guess that it was just > an early feature for dealing with unstable JSONs. +1 I'd very much like it if JSON parse errors and the like didn't result in an empty map but failed the build. I think ideally we could also validate metric expressions using expr.y. If we include expr.y into jevents then is there any need to parse the metric expression at runtime? Could we just generate C code from jevents with a list of events (aka ids) for programming and a dedicated print function for each metric. The events would still be symbolic and checked at runtime, but the expressions being C code could yield compile time errors. Thanks, Ian > Thanks, > john > > > > > jirka > > > >> } > >> > >> - if (process_mapfile(eventsfp, mapfile)) { > >> - pr_info("%s: Error processing mapfile %s\n", prog, mapfile); > >> - /* Make build fail */ > >> + if (process_system_event_tables(eventsfp)) { > >> fclose(eventsfp); > >> - free_arch_std_events(); > >> ret = 1; > >> } > >> > >> - > >> goto out_free_mapfile; > >> > >> empty_map: > >> fclose(eventsfp); > >> create_empty_mapping(output_file); > >> - free_arch_std_events(); > >> out_free_mapfile: > >> + free_arch_std_events(); > >> + free_sys_event_tables(); > >> free(mapfile); > >> return ret; > >> } > > > > SNIP > > > > . > > >
WARNING: multiple messages have this Message-ID (diff)
From: Ian Rogers <irogers@google.com> To: John Garry <john.garry@huawei.com> Cc: Mark Rutland <mark.rutland@arm.com>, Andi Kleen <ak@linux.intel.com>, qiangqing.zhang@nxp.com, Peter Zijlstra <peterz@infradead.org>, will@kernel.org, linuxarm@huawei.com, Arnaldo Carvalho de Melo <acme@kernel.org>, LKML <linux-kernel@vger.kernel.org>, zhangshaokun@hisilicon.com, Alexander Shishkin <alexander.shishkin@linux.intel.com>, Ingo Molnar <mingo@redhat.com>, Namhyung Kim <namhyung@kernel.org>, Jiri Olsa <jolsa@redhat.com>, Linux ARM <linux-arm-kernel@lists.infradead.org>, robin.murphy@arm.com Subject: Re: [PATCH RFC v3 02/12] perf jevents: Add support for system events tables Date: Mon, 11 May 2020 09:21:00 -0700 [thread overview] Message-ID: <CAP-5=fWHipkL6Uq1vMaz-51ETPWajofDXd6RTBMr00pcyooo_g@mail.gmail.com> (raw) In-Reply-To: <9f4ea413-325f-98b4-eb4c-e47aead4f455@huawei.com> On Mon, May 11, 2020 at 8:03 AM John Garry <john.garry@huawei.com> wrote: > > On 11/05/2020 12:01, Jiri Olsa wrote: > > On Thu, May 07, 2020 at 07:57:41PM +0800, John Garry wrote: > > > > SNIP > > > >> + &sys_event_tables); > >> + } > >> + > >> print_events_table_prefix(eventsfp, tblname); > >> return 0; > >> } > >> @@ -1180,7 +1253,6 @@ int main(int argc, char *argv[]) > >> } else if (rc < 0) { > >> /* Make build fail */ > >> fclose(eventsfp); > >> - free_arch_std_events(); > >> ret = 1; > >> goto out_free_mapfile; > >> } else if (rc) { > >> @@ -1206,27 +1278,31 @@ int main(int argc, char *argv[]) > >> if (close_table) > >> print_events_table_suffix(eventsfp); > >> > >> - if (!mapfile) { > >> - pr_info("%s: No CPU->JSON mapping?\n", prog); > >> - goto empty_map; > >> + if (mapfile) { > >> + if (process_mapfile(eventsfp, mapfile)) { > >> + pr_err("%s: Error processing mapfile %s\n", prog, > >> + mapfile); > >> + /* Make build fail */ > >> + fclose(eventsfp); > >> + ret = 1; > >> + } > >> + } else { > >> + pr_err("%s: No CPU->JSON mapping?\n", prog); > > > > shouldn't we jump to empty_map in here? there still needs to be a > > mapfile, right? > > In theory we could only support sys events :) > > But I'll now make this a (empty map) failure case. And I think that > another error case handling needs fixing in my patch. > > > As for this: > > + fprintf(outfp, "struct pmu_sys_events pmu_sys_event_tables[] = {"); > >> + > >> + list_for_each_entry(sys_event_table, &sys_event_tables, list) { > >> + fprintf(outfp, "\n\t{\n\t\t.table = %s,\n\t},", > >> + sys_event_table->name); > >> + } > >> + fprintf(outfp, "\n\t{\n\t\t.table = 0\n\t},"); > > > > this will add extra tabs: > > > > { > > .table = 0 > > }, > > > > while the rest of the file starts items without any indent > > > > I'll ensure the indent is the same. > > BTW, is there anything to be said for removing the empty map feature > (and always breaking the perf build instead)? I guess that it was just > an early feature for dealing with unstable JSONs. +1 I'd very much like it if JSON parse errors and the like didn't result in an empty map but failed the build. I think ideally we could also validate metric expressions using expr.y. If we include expr.y into jevents then is there any need to parse the metric expression at runtime? Could we just generate C code from jevents with a list of events (aka ids) for programming and a dedicated print function for each metric. The events would still be symbolic and checked at runtime, but the expressions being C code could yield compile time errors. Thanks, Ian > Thanks, > john > > > > > jirka > > > >> } > >> > >> - if (process_mapfile(eventsfp, mapfile)) { > >> - pr_info("%s: Error processing mapfile %s\n", prog, mapfile); > >> - /* Make build fail */ > >> + if (process_system_event_tables(eventsfp)) { > >> fclose(eventsfp); > >> - free_arch_std_events(); > >> ret = 1; > >> } > >> > >> - > >> goto out_free_mapfile; > >> > >> empty_map: > >> fclose(eventsfp); > >> create_empty_mapping(output_file); > >> - free_arch_std_events(); > >> out_free_mapfile: > >> + free_arch_std_events(); > >> + free_sys_event_tables(); > >> free(mapfile); > >> return ret; > >> } > > > > SNIP > > > > . > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-11 16:21 UTC|newest] Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-07 11:57 [PATCH RFC v3 00/12] perf pmu-events: Support event aliasing for system PMUs John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 01/12] perf jevents: Add support for an extra directory level John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 02/12] perf jevents: Add support for system events tables John Garry 2020-05-07 11:57 ` John Garry 2020-05-11 11:01 ` Jiri Olsa 2020-05-11 11:01 ` Jiri Olsa 2020-05-11 14:52 ` John Garry 2020-05-11 14:52 ` John Garry 2020-05-11 11:01 ` Jiri Olsa 2020-05-11 11:01 ` Jiri Olsa 2020-05-11 15:02 ` John Garry 2020-05-11 15:02 ` John Garry 2020-05-11 16:21 ` Ian Rogers [this message] 2020-05-11 16:21 ` Ian Rogers 2020-05-12 10:29 ` Jiri Olsa 2020-05-12 10:29 ` Jiri Olsa 2020-05-11 11:01 ` Jiri Olsa 2020-05-11 11:01 ` Jiri Olsa 2020-05-07 11:57 ` [PATCH RFC v3 03/12] perf vendor events arm64: Relocate hip08 events John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 04/12] perf vendor events arm64: Add Architected events smmuv3-pmcg.json John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 05/12] perf vendor events arm64: Add hip08 SMMUv3 PMCG events John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 06/12] perf pmu: Add pmu_id() John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 07/12] perf pmu: Add pmu_add_sys_aliases() John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 08/12] perf vendor events: Add JSON metrics for imx8mm DDR Perf John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 09/12] perf metricgroup: Split up metricgroup__add_metric() John Garry 2020-05-07 11:57 ` John Garry 2020-05-11 11:01 ` Jiri Olsa 2020-05-11 11:01 ` Jiri Olsa 2020-05-11 11:25 ` John Garry 2020-05-11 11:25 ` John Garry 2020-05-11 11:35 ` Joakim Zhang 2020-05-11 11:35 ` Joakim Zhang 2020-05-07 11:57 ` [PATCH RFC v3 10/12] perf metricgroup: Split up metricgroup__print() John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 11/12] perf metricgroup: Support printing metric groups for system PMUs John Garry 2020-05-07 11:57 ` John Garry 2020-05-07 11:57 ` [PATCH RFC v3 12/12] perf metricgroup: Support adding metrics " John Garry 2020-05-07 11:57 ` John Garry 2020-05-08 2:55 ` [PATCH RFC v3 00/12] perf pmu-events: Support event aliasing " Joakim Zhang 2020-05-08 2:55 ` Joakim Zhang 2020-05-12 8:02 ` Joakim Zhang 2020-05-12 8:02 ` Joakim Zhang 2020-05-12 10:13 ` John Garry 2020-05-12 10:13 ` John Garry 2020-05-12 10:30 ` Joakim Zhang 2020-05-12 10:30 ` Joakim Zhang
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='CAP-5=fWHipkL6Uq1vMaz-51ETPWajofDXd6RTBMr00pcyooo_g@mail.gmail.com' \ --to=irogers@google.com \ --cc=acme@kernel.org \ --cc=ak@linux.intel.com \ --cc=alexander.shishkin@linux.intel.com \ --cc=john.garry@huawei.com \ --cc=jolsa@redhat.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxarm@huawei.com \ --cc=mark.rutland@arm.com \ --cc=mingo@redhat.com \ --cc=namhyung@kernel.org \ --cc=peterz@infradead.org \ --cc=qiangqing.zhang@nxp.com \ --cc=robin.murphy@arm.com \ --cc=will@kernel.org \ --cc=zhangshaokun@hisilicon.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: linkBe 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.