From: Cody P Schafer <cody@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
Linux PPC <linuxppc-dev@lists.ozlabs.org>
Cc: Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/8] perf: add PMU_RANGE_ATTR() helper for use by sw-like pmus
Date: Mon, 03 Feb 2014 13:19:42 -0800 [thread overview]
Message-ID: <52F007EE.3090500@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140201055805.6FF982C00AF@ozlabs.org>
On 01/31/2014 09:58 PM, Michael Ellerman wrote:
> On Thu, 2014-16-01 at 23:53:47 UTC, Cody P Schafer wrote:
>> Add PMU_RANGE_ATTR() and PMU_RANGE_RESV() (for reserved areas) which
>> generate functions to extract the relevent bits from
>> event->attr.config{,1,2} for use by sw-like pmus where the
>> 'config{,1,2}' values don't map directly to hardware registers.
>
> This is neat.
>
> The split of the macros is a bit weird, ie. PMU_RANGE_RESV() doesn't really do
> what it's name suggests.
>
> I think you want one macro which creates the accessors, with a name that
> reflects that - yeah I can't think of a good one right now, but "event" should
> probably be in there because that's what it operates on.
>
> Having a macro for the reserved regions is good, but you MUST actually check
> that the reserved regions are zero. Otherwise you are permitting your caller to
> pass junk in there and you then can't unreserved them in a future version of
> the API.
>
> So I think a macro that gives you a special reserved region routine would be
> good, so you can write something like:
>
> if (event_check_reserved1() || event_check_reserved2())
> return -EINVAL;
>
The way it's set up right now, RESV is just a hint to the user of the
PMU_RANGE_ATTR() and PMU_RANGE_RESV() macros to indicate which to use.
RESV simply avoids creating an attr format which would go unused only in
the case where the range is a reserved one (and gcc would complain about
it).
I don't like the "event_check_foo()" bit because that is actually
identical to "event_get_foo()", I don't see a point in generating
differently named functions that do exactly the same thing.
The current user (hv-24x7.c) of PMU_RANGE_RESV() already does the
appropriate checking:
if (event_get_reserved1(event) ||
event_get_reserved2(event) ||
event_get_reserved3(event)) {
pr_devel("reserved set when forbidden 0x%llx(0x%llx) 0x%llx(0x%llx)
0x%llx(0x%llx)\n",
event->attr.config,
event_get_reserved1(event),
event->attr.config1,
event_get_reserved2(event),
event->attr.config2,
event_get_reserved3(event));
return -EINVAL;
}
WARNING: multiple messages have this Message-ID (diff)
From: Cody P Schafer <cody@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
Linux PPC <linuxppc-dev@lists.ozlabs.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>, Paul Mackerras <paulus@samba.org>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Subject: Re: [PATCH 1/8] perf: add PMU_RANGE_ATTR() helper for use by sw-like pmus
Date: Mon, 03 Feb 2014 13:19:42 -0800 [thread overview]
Message-ID: <52F007EE.3090500@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140201055805.6FF982C00AF@ozlabs.org>
On 01/31/2014 09:58 PM, Michael Ellerman wrote:
> On Thu, 2014-16-01 at 23:53:47 UTC, Cody P Schafer wrote:
>> Add PMU_RANGE_ATTR() and PMU_RANGE_RESV() (for reserved areas) which
>> generate functions to extract the relevent bits from
>> event->attr.config{,1,2} for use by sw-like pmus where the
>> 'config{,1,2}' values don't map directly to hardware registers.
>
> This is neat.
>
> The split of the macros is a bit weird, ie. PMU_RANGE_RESV() doesn't really do
> what it's name suggests.
>
> I think you want one macro which creates the accessors, with a name that
> reflects that - yeah I can't think of a good one right now, but "event" should
> probably be in there because that's what it operates on.
>
> Having a macro for the reserved regions is good, but you MUST actually check
> that the reserved regions are zero. Otherwise you are permitting your caller to
> pass junk in there and you then can't unreserved them in a future version of
> the API.
>
> So I think a macro that gives you a special reserved region routine would be
> good, so you can write something like:
>
> if (event_check_reserved1() || event_check_reserved2())
> return -EINVAL;
>
The way it's set up right now, RESV is just a hint to the user of the
PMU_RANGE_ATTR() and PMU_RANGE_RESV() macros to indicate which to use.
RESV simply avoids creating an attr format which would go unused only in
the case where the range is a reserved one (and gcc would complain about
it).
I don't like the "event_check_foo()" bit because that is actually
identical to "event_get_foo()", I don't see a point in generating
differently named functions that do exactly the same thing.
The current user (hv-24x7.c) of PMU_RANGE_RESV() already does the
appropriate checking:
if (event_get_reserved1(event) ||
event_get_reserved2(event) ||
event_get_reserved3(event)) {
pr_devel("reserved set when forbidden 0x%llx(0x%llx) 0x%llx(0x%llx)
0x%llx(0x%llx)\n",
event->attr.config,
event_get_reserved1(event),
event->attr.config1,
event_get_reserved2(event),
event->attr.config2,
event_get_reserved3(event));
return -EINVAL;
}
next prev parent reply other threads:[~2014-02-03 21:19 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-16 23:53 [PATCH 0/8] Add support for PowerPC Hypervisor supplied performance counters Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-01-16 23:53 ` [PATCH 1/8] perf: add PMU_RANGE_ATTR() helper for use by sw-like pmus Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-02-01 5:58 ` Michael Ellerman
2014-02-03 21:19 ` Cody P Schafer [this message]
2014-02-03 21:19 ` Cody P Schafer
2014-01-16 23:53 ` [PATCH 2/8] perf core: export swevent hrtimer helpers Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-02-01 5:58 ` Michael Ellerman
2014-01-16 23:53 ` [PATCH 3/8] powerpc: add hvcalls for 24x7 and gpci (get performance counter info) Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-02-01 5:58 ` Michael Ellerman
2014-02-03 21:21 ` Cody P Schafer
2014-02-03 21:21 ` Cody P Schafer
2014-01-16 23:53 ` [PATCH 4/8] powerpc: add hv_gpci interface header Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-02-01 5:58 ` Michael Ellerman
2014-02-03 21:40 ` Cody P Schafer
2014-02-03 21:40 ` Cody P Schafer
2014-02-05 23:14 ` Cody P Schafer
2014-02-05 23:14 ` Cody P Schafer
2014-01-16 23:53 ` [PATCH 5/8] powerpc: add 24x7 " Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-02-01 5:58 ` Michael Ellerman
2014-01-16 23:53 ` [PATCH 6/8] powerpc/perf: add support for the hv gpci (get performance counter info) interface Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-02-01 5:58 ` Michael Ellerman
2014-02-03 21:13 ` Cody P Schafer
2014-02-03 21:13 ` Cody P Schafer
2014-01-16 23:53 ` [PATCH 7/8] powerpc/perf: add support for the hv 24x7 interface Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-01-16 23:53 ` [PATCH 8/8] powerpc/perf: add kconfig option for hypervisor provided counters Cody P Schafer
2014-01-16 23:53 ` Cody P Schafer
2014-01-22 1:32 ` [PATCH 0/8] Add support for PowerPC Hypervisor supplied performance counters Michael Ellerman
2014-01-22 1:32 ` Michael Ellerman
2014-01-22 9:37 ` Anshuman Khandual
2014-01-22 9:37 ` Anshuman Khandual
2014-01-23 0:11 ` Cody P Schafer
2014-01-23 0:11 ` Cody P Schafer
2014-01-31 20:59 ` Cody P Schafer
2014-01-31 20:59 ` Cody P Schafer
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=52F007EE.3090500@linux.vnet.ibm.com \
--to=cody@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.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 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.