All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: 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.