public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Richard Henderson <richard.henderson@linaro.org>
Cc: Shaokun Zhang <zhangshaokun@hisilicon.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: perf: Simplify the ARMv8 PMUv3 event attributes
Date: Thu, 31 Oct 2019 07:55:06 +0000	[thread overview]
Message-ID: <20191031075505.GA3412@blommer> (raw)
In-Reply-To: <b603fc49-01f5-b5b4-7c2c-5f0bc53b6fc1@linaro.org>

On Wed, Oct 30, 2019 at 02:34:37PM +0100, Richard Henderson wrote:
> On 10/30/19 4:46 AM, Shaokun Zhang wrote:
> > For each PMU event, there is a ARMV8_EVENT_ATTR(xx, XX) and
> > &armv8_event_attr_xx.attr.attr. Let's redefine the ARMV8_EVENT_ATTR
> > to simplify the armv8_pmuv3_event_attrs.
> ...
> >  #define ARMV8_EVENT_ATTR(name, config) \
> > +	(&((struct perf_pmu_events_attr[]) { \
> > +		{ .attr = __ATTR(name, 0444, armv8pmu_events_sysfs_show, NULL), \
> > +		  .id = config, } \
> > +	})[0].attr.attr)
> >  
> >  static struct attribute *armv8_pmuv3_event_attrs[] = {
> > +	ARMV8_EVENT_ATTR(sw_incr, ARMV8_PMUV3_PERFCTR_SW_INCR),
> 
> You do realize this creates complete perf_pmu_events_attr structures, most of
> which is unused and unreachable, right?

In armv8pmu_events_sysfs_show() we use container_of() to access the
perf_pmu_events_attr, and extracts the id field:

| static ssize_t
| armv8pmu_events_sysfs_show(struct device *dev,
|                            struct device_attribute *attr, char *page)
| {
|         struct perf_pmu_events_attr *pmu_attr;
| 
|         pmu_attr = container_of(attr, struct perf_pmu_events_attr, attr);
| 
|         return sprintf(page, "event=0x%03llx\n", pmu_attr->id);
| }

> Also, why not take the opportunity to assert that the armv8_pmuv3_event_attrs
> array cannot get out of sync with the ARMV8_PMUV3_* defines?
> 
> Slightly better would seem to be
> 
> #define ARMV8_EVENT_ATTR(name, config) \
> 	[config] = &((struct device_attribute) \
> 		__ATTR(name, 0444, armv8pmu_events_sysfs_show, NULL)).attr

I'm not sure I follow. This is not equivalent, and you're using the config
field in a very different way -- that's not an index in the parent array in the
current code. How do you expect armv8pmu_events_sysfs_show to get the config
value in this case?

> 
> though I'm not sure why __ATTR is particularly desired above
> 
> #define ARMV8_EVENT_ATTR(name, config)      \
> 	[config] = &(struct attribute){     \
> 		.name = __stringify(name),  \
> 		.mode = 0444,               \
> 	}

Using __ATTR is consistent with other drivers, so I don't see a reason to
change that unless there's a significant simplification, or a functional
improvement

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-10-31  7:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30  3:46 [PATCH] arm64: perf: Simplify the ARMv8 PMUv3 event attributes Shaokun Zhang
2019-10-30 13:34 ` Richard Henderson
2019-10-31  7:55   ` Mark Rutland [this message]
2019-10-31  8:45   ` Shaokun Zhang
2019-10-31 16:08 ` Will Deacon
2019-11-01  3:45   ` Shaokun Zhang
2019-11-01  8:53   ` Mark Rutland
2019-11-01 10:36     ` Will Deacon
2019-11-01 10:54       ` Robin Murphy
2019-11-01 10:55         ` Will Deacon
2019-11-01 11:11           ` Robin Murphy
2019-11-01 14:36             ` Mark Rutland
2019-11-01 16:05               ` Will Deacon
2019-11-04  2:02             ` Shaokun Zhang
2019-11-04  3:25               ` Shaokun Zhang
2019-11-04  1:02           ` Shaokun Zhang
2019-11-04  3:18             ` Shaokun Zhang
2019-11-01 14:32       ` Mark Rutland

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=20191031075505.GA3412@blommer \
    --to=mark.rutland@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=richard.henderson@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox