public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jing Zhang <renyu.zj@linux.alibaba.com>
To: Ian Rogers <irogers@google.com>
Cc: John Garry <john.g.garry@oracle.com>,
	Will Deacon <will@kernel.org>, James Clark <james.clark@arm.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-perf-users@vger.kernel.org, linux-doc@vger.kernel.org,
	Zhuo Song <zhuo.song@linux.alibaba.com>,
	Shuai Xue <xueshuai@linux.alibaba.com>
Subject: Re: [PATCH v6 3/7] perf jevents: Support more event fields
Date: Tue, 15 Aug 2023 20:24:17 +0800	[thread overview]
Message-ID: <a5a5ca95-e4c7-74a9-c875-9feea7a1b642@linux.alibaba.com> (raw)
In-Reply-To: <CAP-5=fXFZffdRMFH+aFzFech2pjbfYyQ+fx+E-YnfMBHifD4gw@mail.gmail.com>



在 2023/8/15 上午6:31, Ian Rogers 写道:
> On Mon, Aug 7, 2023 at 12:51 AM Jing Zhang <renyu.zj@linux.alibaba.com> wrote:
>>
>> The usual event descriptions are "event=xxx" or "config=xxx", while the
>> event descriptions of CMN are "type=xxx, eventid=xxx" or more complex.
> 
> I found this difficult to read in relation to the code. Perhaps:
> 
> The previous code assumes an event has either an "event=" or "config"
> field at the beginning. For CMN neither of these may be present, as an
> event is typically "type=xx,eventid=xxx".
> 

Thank you for providing a more accurate and readable description.
I was indeed struggling with how to describe the problem more accurately before.

> I think the use of the name "type" here is unfortunate. It conflicts
> with the PMU's type as defined in perf_event_attr.
> 

I agree, but it would require modifying the driver, which is not currently being
considered. In the meantime, I can describe the event_field as ('NodeType', 'type=').

> In general I think the jevents.py code needs improving, the
> event_fields dictionary is convoluted, we shouldn't be afraid to
> change the event json for example to get rid of things like ExtSel, we
> should really ensure the formats in the events are valid for the PMU
> they are for.
> 
>> $cat /sys/bus/event_source/devices/arm_cmn_0/events/hnf_cache_fill
>> type=0x5,eventid=0x3
>>
>> When adding aliases for events described as "event=xxx" or "config=xxx",
>> EventCode or ConfigCode can be used in the JSON files to describe the
>> events. But "eventid=xxx, type=xxx" cannot be supported at present.
>>
>> If EventCode and ConfigCode is not added in the alias JSON file, the
>> event description will add "event=0" by default. So, even if the event
>> field is added to supplement "eventid=xxx" and "type=xxx", the final
>> parsing result will be "event=0, eventid=xxx, type=xxx".
>>
>> Therefore, when EventCode and ConfigCode are missing in JSON, "event=0" is
>> no longer added by default. EventIdCode and Type are added to the event
>> field, and ConfigCode is moved into the event_field array which can also
>> guarantee its original function.
> 
> A useful test can be to build with JEVENTS_ARCH=all and confirm the
> before and after change generated pmu-events.c is the same.
> 

Okay, I will test it right away.

>> Signed-off-by: Jing Zhang <renyu.zj@linux.alibaba.com>
>> ---
>>  tools/perf/pmu-events/jevents.py | 21 +++++++++++++--------
>>  1 file changed, 13 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/perf/pmu-events/jevents.py b/tools/perf/pmu-events/jevents.py
>> index f57a8f2..9c0f63a 100755
>> --- a/tools/perf/pmu-events/jevents.py
>> +++ b/tools/perf/pmu-events/jevents.py
>> @@ -275,12 +275,6 @@ class JsonEvent:
>>        }
>>        return table[unit] if unit in table else f'uncore_{unit.lower()}'
>>
>> -    eventcode = 0
>> -    if 'EventCode' in jd:
>> -      eventcode = int(jd['EventCode'].split(',', 1)[0], 0)
>> -    if 'ExtSel' in jd:
>> -      eventcode |= int(jd['ExtSel']) << 8
>> -    configcode = int(jd['ConfigCode'], 0) if 'ConfigCode' in jd else None
>>      self.name = jd['EventName'].lower() if 'EventName' in jd else None
>>      self.topic = ''
>>      self.compat = jd.get('Compat')
>> @@ -317,7 +311,15 @@ class JsonEvent:
>>      if precise and self.desc and '(Precise Event)' not in self.desc:
>>        extra_desc += ' (Must be precise)' if precise == '2' else (' (Precise '
>>                                                                   'event)')
>> -    event = f'config={llx(configcode)}' if configcode is not None else f'event={llx(eventcode)}'
>> +    eventcode = None
>> +    if 'EventCode' in jd:
>> +      eventcode = int(jd['EventCode'].split(',', 1)[0], 0)
>> +    if 'ExtSel' in jd:
>> +      if eventcode is None:
>> +        eventcode = int(jd['ExtSel']) << 8
>> +      else:
>> +        eventcode |= int(jd['ExtSel']) << 8
>> +    event = f'event={llx(eventcode)}' if eventcode is not None else None
>>      event_fields = [
>>          ('AnyThread', 'any='),
>>          ('PortMask', 'ch_mask='),
>> @@ -327,10 +329,13 @@ class JsonEvent:
>>          ('Invert', 'inv='),
>>          ('SampleAfterValue', 'period='),
>>          ('UMask', 'umask='),
>> +        ('ConfigCode', 'config='),
> 
> This loses the int and potential base conversion of ConfigCode.
> Clearly the code was taking care to maintain this behavior so I
> suspect this change has broken something. JEVENTS_ARCH=all should
> reveal the answer.
> 

You are correct, I compared the generated pmu-events.c files before and after,
and they are indeed different, with before:config=0x5 vs after:config=0x05. I will keep the
original way of handling ConfigCode in the next version.

>> +        ('Type', 'type='),
>> +        ('EventIdCode', 'eventid='),
>>      ]
>>      for key, value in event_fields:
>>        if key in jd and jd[key] != '0':
>> -        event += ',' + value + jd[key]
>> +        event = event + ',' + value + jd[key] if event is not None else value + jd[key]
> 
> Perhaps initialize event above to the empty string then:
> 
> if key in jd and jd[key] != '0':
>   if event:
>      event += ','
>   event += value + jd[key]
> 

If the event is None, the statement event += value + jd[key] would result in an error.
So, maybe I can use the following way:

if event:
    event += ',' + value + jd[key]
else:
    event = value + jd[key]


Thanks,
Jing

  reply	other threads:[~2023-08-15 12:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07  7:51 [PATCH v6 0/7] Add aliases and metrics for Arm CMN Jing Zhang
2023-08-07  7:51 ` [PATCH v6 1/7] perf pmu: "Compat" supports matching multiple identifiers Jing Zhang
2023-08-07  9:19   ` John Garry
2023-08-07  7:51 ` [PATCH v6 2/7] perf metric: " Jing Zhang
2023-08-07  9:20   ` John Garry
2023-08-07  7:51 ` [PATCH v6 3/7] perf jevents: Support more event fields Jing Zhang
2023-08-07  9:24   ` John Garry
2023-08-07 11:52     ` Jing Zhang
2023-08-14  6:08     ` Jing Zhang
2023-08-14 22:31   ` Ian Rogers
2023-08-15 12:24     ` Jing Zhang [this message]
2023-08-07  7:51 ` [PATCH v6 4/7] perf test: Fix matching_pmu Jing Zhang
2023-08-07  9:21   ` John Garry
2023-08-07 12:02     ` Jing Zhang
2023-08-07  7:51 ` [PATCH v6 5/7] perf test: Add pmu-event test for "Compat" and new event_field Jing Zhang
2023-08-07  9:23   ` John Garry
2023-08-15  1:11   ` Ian Rogers
2023-08-15 12:33     ` Jing Zhang
2023-08-07  7:51 ` [PATCH v6 6/7] perf jevents: Add support for Arm CMN PMU aliasing Jing Zhang
2023-08-14 22:36   ` Ian Rogers
2023-08-15 12:43     ` Jing Zhang
2023-08-07  7:51 ` [PATCH v6 7/7] perf vendor events: Add JSON metrics for Arm CMN Jing 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=a5a5ca95-e4c7-74a9-c875-9feea7a1b642@linux.alibaba.com \
    --to=renyu.zj@linux.alibaba.com \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=irogers@google.com \
    --cc=james.clark@arm.com \
    --cc=john.g.garry@oracle.com \
    --cc=jolsa@kernel.org \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    --cc=xueshuai@linux.alibaba.com \
    --cc=zhuo.song@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox