linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jolsa@redhat.com (Jiri Olsa)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/5] perf jevents: add support for arch recommended events
Date: Mon, 8 Jan 2018 15:08:40 +0100	[thread overview]
Message-ID: <20180108140840.GB17156@krava> (raw)
In-Reply-To: <850a0774-9442-c836-f457-69e1e0d72fb2@huawei.com>

On Thu, Jan 04, 2018 at 05:17:56PM +0000, John Garry wrote:

SNIP

> 
> 
> Hi Jirka,
> 
> Sorry for the slow reply.

np, just got back from holidays anyway ;-)

> 
> > > > Won't this all potentially have a big maintainence cost?
> > as Andi said it's mostly just the disk space,
> > which is not big deal
> > 
> > I'm not doing JSON file updates, but I think having
> > simple single dir for platform/cpu could save us some
> > confusion in future
> 
> Understood. But for ARM, which has very standardised architecture events, it
> is good to reduce this event duplication between platforms.
> 
> > 
> > however I won't oppose if you want to add this logic,
> > but please:
> >   - use the list_head ;-)
> 
> Of course
> 
> >   - leave the process_one_file function simple
> >     and separate the level0 processing
> 
> ok, this is how it should look already, albeit a couple of
> process_one_file() modifications. I'll re-check this.
> 
> >   - you are using 'EventCode' as an unique ID to find
> >     the base, but it's not unique for x86, you'll need
> >     to add some other ID scheme that fits to all archs
> 
> Right, so you mentioned earlier using a new keyword token to identify
> whether we use the standard event, so we can go his way - ok?

yes, something like that

> I would also like to mention at this point why I did the event
> pre-processing in jevents, and not a separate script:
> - current build does not transverse the arch tree
> 	- tree transversal for JSON processing is done in jevents
> - a script would mean derived objects, which means:
> 	- makefile changes for derived objects
> 	- jevents would have to deal with derived objects
> - jevents already has support for JSON processing
> 
> The advantage of using a script is that we keep the JSON processing in
> jevents simple.

I don't mind the extra functionality in jevents as long as the current
one keeps on working and the new one works for all archs ;-)

thanks,
jirka

  reply	other threads:[~2018-01-08 14:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-05 16:13 [RFC PATCH 0/5] perf events patches for improved ARM64 support John Garry
2017-12-05 16:13 ` [RFC PATCH 1/5] perf jevents: add support for pmu events vendor subdirectory John Garry
2017-12-06 13:38   ` Jiri Olsa
2017-12-06 14:41     ` John Garry
2017-12-05 16:13 ` [RFC PATCH 2/5] perf jevents: add support for arch recommended events John Garry
2017-12-05 17:27   ` Andi Kleen
2017-12-06  8:34     ` John Garry
2017-12-06 13:36   ` Jiri Olsa
2017-12-06 15:20     ` John Garry
2017-12-08 12:29       ` Jiri Olsa
2017-12-08 15:42         ` John Garry
2017-12-09  7:31           ` Jiri Olsa
2017-12-11 10:25             ` John Garry
2017-12-15 11:22             ` John Garry
2017-12-16 18:47               ` Andi Kleen
2018-01-02 12:07                 ` John Garry
2018-01-02 17:48                   ` Andi Kleen
2018-01-03 12:22                     ` John Garry
2017-12-21 19:39               ` Jiri Olsa
2018-01-04 17:17                 ` John Garry
2018-01-08 14:08                   ` Jiri Olsa [this message]
2017-12-06 13:37   ` Jiri Olsa
2017-12-06 14:40     ` John Garry
2017-12-08 12:31       ` Jiri Olsa
2017-12-08 15:38         ` John Garry
2017-12-09  7:26           ` Jiri Olsa
2017-12-05 16:13 ` [RFC PATCH 3/5] perf vendor events arm64: add armv8 recommended events JSON John Garry
2017-12-05 16:13 ` [RFC PATCH 4/5] perf vendor events arm64: relocate thunderx2 JSON John Garry
2017-12-05 16:13 ` [RFC PATCH 5/5] perf vendor events arm64: add HiSilicon hip08 JSON John Garry
2017-12-06 16:42 ` [RFC PATCH 0/5] perf events patches for improved ARM64 support William Cohen
2017-12-06 17:35   ` John Garry

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=20180108140840.GB17156@krava \
    --to=jolsa@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).