linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Jing Zhang <renyu.zj@linux.alibaba.com>,
	John Garry <john.g.garry@oracle.com>,
	Ian Rogers <irogers@google.com>, Will Deacon <will@kernel.org>,
	James Clark <james.clark@arm.com>,
	Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Ilkka Koskinen <ilkka@os.amperecomputing.com>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-perf-users@vger.kernel.org,
	Shuai Xue <xueshuai@linux.alibaba.com>,
	Zhuo Song <zhuo.song@linux.alibaba.com>
Subject: Re: [PATCH RFC 1/4] driver/perf: Add identifier sysfs file for CMN
Date: Wed, 29 Mar 2023 18:47:41 +0100	[thread overview]
Message-ID: <091d5b8d-6ea7-e6ff-3421-63612797ac60@arm.com> (raw)
In-Reply-To: <8ba831ae-4568-32af-3fd1-fd51a7c13dcd@linux.alibaba.com>

On 2023-03-29 12:53, Jing Zhang wrote:
> 
> 
> 在 2023/3/27 下午3:55, John Garry 写道:
>> On 27/03/2023 03:46, Jing Zhang wrote:
>>> To allow userspace to identify the specific implementation of the device,
>>> add an "identifier" sysfs file.
>>>
>>> The perf tool can match the arm CMN metric through the identifier.
>>>
>>> Signed-off-by: Jing Zhang <renyu.zj@linux.alibaba.com>
>>> ---
>>>    drivers/perf/arm-cmn.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>>>    1 file changed, 43 insertions(+)
>>>
>>> diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
>>> index c968986..0c138ad 100644
>>> --- a/drivers/perf/arm-cmn.c
>>> +++ b/drivers/perf/arm-cmn.c
>>> @@ -1168,10 +1168,53 @@ static ssize_t arm_cmn_cpumask_show(struct device *dev,
>>>        .attrs = arm_cmn_cpumask_attrs,
>>>    };
>>>    +static ssize_t arm_cmn_identifier_show(struct device *dev,
>>> +        struct device_attribute *attr, char *buf)
>>> +{
>>> +    struct arm_cmn *cmn = to_cmn(dev_get_drvdata(dev));
>>> +    if (cmn->model == CMN700) {
>>> +        return sysfs_emit(buf, "%s\n", "CMN700");
>>
>> Is it possible to have a pointer to this string in struct arm_cmn, such that we don't have to do this model to identifier lookup here? If-else chains like this are not scalable.
>>
> Will do.
> 
>> BTW, does this HW have some HW identifier register, like iidr? I think that using that may be preferable.
>>
> 
> I didn't find the relevant identifier register.
> 
> Do Illka and Robin know that there is such a register that can identify different CMN versions? Looking forward to your suggestions.

In principle the "part number" fields from CFGM_PERIPH_ID_0/1 are 
supposed to identify the model, but for various reasons I'm suspicious 
of that being unreliable (not least that no actual values are 
documented, only "configuration-dependent"). That's why I went down the 
route of making sure we have explicit ACPI/DT identifiers for every model.

However, the model alone seems either too specific or not specific 
enough for a jevents identifier. The defined metrics are pretty trivial 
and should have no real reason not to be common to *any* CMN PMU where 
the underlying events are present. On the other hand, if we want to get 
down to the level of specific events in JSON then we'd need to consider 
the revision as well, since there are several events which only exist on 
certain revisions of a given model (but often are also common to later 
models).

This actually foreshadows a question I was planning to bring up in the 
context of another driver I'm working on - for this one I would rather 
like to try using jevents rather than have to maintain another sprawl of 
event tables in a driver, but it's still going to have the same thing of 
wanting model/revision matching along the lines of what 
arm_cmn_event_attr_is_visible() is doing for CMN events. AFAICS this 
would need jevents to grow a rather more flexible way of encoding and 
matching identifiers, since having dozens of almost-identical copies of 
event definitions for every exact identifier value is clearly 
unworkable. Does anyone happen to have any thoughts or preferences 
around how that might be approached?

>>> +    }
>>> +    else if (cmn->model == CMN650) {
>>> +        return sysfs_emit(buf, "%s\n", "CMN650");
>>
>> I'd use lowercase names
>>
> Ok.
> 
>>> +    }
>>> +    else if (cmn->model == CMN600) {
>>> +        return sysfs_emit(buf, "%s\n", "CMN600");
>>> +    }
>>> +    else if (cmn->model == CI700) {
>>> +        return sysfs_emit(buf, "%s\n", "CI700");
>>> +    }
>>> +    return sysfs_emit(buf, "%s\n", "UNKNOWN");
>>
>> can we have a "is_visble" attr to just no show this when unknown?

No need - it will never be unknown unless someone goes out of their way 
to break the probing code and/or match_data.

>>
> 
> Ok.
> 
>>> +}
>>> +
>>> +static umode_t arm_cmn_identifier_attr_visible(struct kobject *kobj,
>>> +        struct attribute *attr, int n)
>>> +{
>>> +    struct device *dev = kobj_to_dev(kobj);
>>> +    struct arm_cmn *cmn = to_cmn(dev_get_drvdata(dev));
>>> +    if (cmn->model <= 0)
>>> +        return 0;
>>> +    return attr->mode;
>>> +};

As above, "cmn->model <= 0" can never be true.

Thanks,
Robin.

>>> +
>>> +static struct device_attribute arm_cmn_identifier_attr =
>>> +__ATTR(identifier, 0444, arm_cmn_identifier_show, NULL);
>>> +
>>> +static struct attribute *arm_cmn_identifier_attrs[] = {
>>> +    &arm_cmn_identifier_attr.attr,
>>> +    NULL,
>>
>> nit: no need for trailing ',' on a sentinel
>>
> 
> Ok, Will do.
> 
>>> +};
>>> +
>>> +static struct attribute_group arm_cmn_identifier_attr_group = {
>>> +    .attrs = arm_cmn_identifier_attrs,
>>> +    .is_visible = arm_cmn_identifier_attr_visible,
>>> +};
>>> +
>>>    static const struct attribute_group *arm_cmn_attr_groups[] = {
>>>        &arm_cmn_event_attrs_group,
>>>        &arm_cmn_format_attrs_group,
>>>        &arm_cmn_cpumask_attr_group,
>>> +    &arm_cmn_identifier_attr_group,
>>>        NULL
>>>    };
>>>    

  reply	other threads:[~2023-03-29 17:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27  2:46 [PATCH RFC 0/4] Add JSON metrics for arm CMN and Yitian710 DDR Jing Zhang
2023-03-27  2:46 ` [PATCH RFC 1/4] driver/perf: Add identifier sysfs file for CMN Jing Zhang
2023-03-27  7:55   ` John Garry
2023-03-29 11:53     ` Jing Zhang
2023-03-29 17:47       ` Robin Murphy [this message]
2023-03-30 15:55         ` John Garry
2023-03-27  2:46 ` [PATCH RFC 2/4] perf vendor events: Add JSON metrics for cmn700 Jing Zhang
2023-03-27  2:46 ` [PATCH RFC 3/4] driver/perf: Add identifier sysfs file for Yitian 710 DDR Jing Zhang
2023-03-29  7:55   ` Shuai Xue
2023-03-29 12:03     ` Jing Zhang
2023-03-27  2:46 ` [PATCH RFC 4/4] perf vendor events: Add JSON metrics " Jing Zhang
2023-03-27 16:51 ` [PATCH RFC 0/4] Add JSON metrics for arm CMN and Yitian710 DDR Ian Rogers
2023-03-29 11:59   ` 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=091d5b8d-6ea7-e6ff-3421-63612797ac60@arm.com \
    --to=robin.murphy@arm.com \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=ilkka@os.amperecomputing.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-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=namhyung@kernel.org \
    --cc=renyu.zj@linux.alibaba.com \
    --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;
as well as URLs for NNTP newsgroup(s).