From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Vince Weaver <vince@deater.net>,
Stephane Eranian <eranian@google.com>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Will Deacon <will.deacon@arm.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure
Date: Wed, 1 Feb 2017 14:33:46 -0700 [thread overview]
Message-ID: <CANLsYkz2iU2dUwshj8zYd1ix0yKtNYkMmYZ=cr4nLdq3efvUMQ@mail.gmail.com> (raw)
In-Reply-To: <87wpda9iyv.fsf@ashishki-desk.ger.corp.intel.com>
)
On 1 February 2017 at 05:46, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Mathieu Poirier <mathieu.poirier@linaro.org> writes:
>
>> On 27 January 2017 at 05:12, Alexander Shishkin
>> <alexander.shishkin@linux.intel.com> wrote:
>>> But "range" is not an action, it's a type of a filter. It determines the
>>> condition that triggers an action. An action, however, is what we do
>>> when the condition comes true.
>>
>> Then filter->action could be renamed 'type'.
>
> No. Again, *action* is what we *do*. *Type* is *how* we detect that
> something needs to be done.
If this is what you want to convey then
+ * @action: filter/start/stop
needs to be fixed. This can be interpreted as "use range filter,
start filter or stop filter" - which is exactly what I did. Something
like
+ * @action: 1: start filtering 0: stop filtering
will avoid any confusion.
>
>> In the end filters on PT
>> are range filters, the same way they are on CS. But changing the
>
> No. The CS driver supports both single address and address range
> filters at least acconding to my reading of the code. Now that I look
> more at it, I see that it also gets the range filters wrong: it
> disregards filter->filter for range filters, assuming that since it's a
> range, it means that the user wants to trace what's in the range
> (filter->filter == 1), but it may also mean "stop if you end up in this
> range" (filter->filter == 0).
Exactly. The code does the right thing based on my interpretation of
the comment found in the code:
* @range: 1: range, 0: address
* @filter: 1: filter/start, 0: stop
That is @range to determine if we are using a range or an address
filter and @filter to specify what kind of address filter to use
(start or stop). Ignoring range filters when ->filter == 0 was done
on purpose as I simply couldn't see how to fit it in.
> The fact that the CS driver gets it wrong
> just proves the point that "filter->filter" is confusing and misleading
> and needs to be replaced.
>
I could not agree more.
On the flip side it doesn't change anything to my original argument:
the code should not be made to be smart. If a range filter is used
then a size of zero should be treated as an error.
To move forward please keep the current functionality on the CS side,
i.e return -EINVAL when a size of zero is used with a range filter.
Once it is queued I'll send a set of patches to support the exclusion
of address ranges.
> In the case of CS, I think that a -EOPNOTSUPP is also appropriate for
> the type==range&&action==stop combination.
That will also be part of said patches.
Thanks,
Mathieu
>
> Regards,
> --
> Alex
next prev parent reply other threads:[~2017-02-01 21:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 9:40 [PATCH 0/3] perf: Updates for address filters Alexander Shishkin
2017-01-26 9:40 ` [PATCH 1/3] perf, pt, coresight: Clean up address filter structure Alexander Shishkin
2017-01-26 13:02 ` kbuild test robot
2017-01-26 13:24 ` Alexander Shishkin
2017-01-26 18:26 ` Mathieu Poirier
2017-01-27 12:12 ` Alexander Shishkin
2017-01-27 17:17 ` Mathieu Poirier
2017-02-01 12:46 ` Alexander Shishkin
2017-02-01 21:33 ` Mathieu Poirier [this message]
2017-02-01 22:15 ` Mathieu Poirier
2017-02-02 10:42 ` Alexander Shishkin
2017-02-02 17:36 ` Mathieu Poirier
2017-02-02 16:22 ` Alexander Shishkin
2017-02-07 17:50 ` Mathieu Poirier
[not found] ` <20180117123137.3hlmudzu5eogl53n@ukko.fi.intel.com>
2018-01-18 16:59 ` Mathieu Poirier
2018-01-18 17:06 ` Will Deacon
2018-01-18 18:19 ` Mathieu Poirier
2018-01-19 18:50 ` Mathieu Poirier
2017-01-26 9:40 ` [PATCH 2/3] perf: Do error out on a kernel filter on an exclude_filter event Alexander Shishkin
2017-01-26 18:32 ` Mathieu Poirier
2017-02-10 8:33 ` [tip:perf/core] perf/core: " tip-bot for Alexander Shishkin
2017-01-26 9:40 ` [PATCH 3/3] perf: Allow kernel filters on cpu events Alexander Shishkin
2017-01-26 21:38 ` Mathieu Poirier
2017-01-27 12:31 ` Alexander Shishkin
2017-01-27 17:38 ` Mathieu Poirier
2017-02-10 8:07 ` Ingo Molnar
2017-02-14 12:59 ` Alexander Shishkin
2017-02-10 8:34 ` [tip:perf/core] perf/core: Allow kernel filters on CPU events tip-bot for Alexander Shishkin
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='CANLsYkz2iU2dUwshj8zYd1ix0yKtNYkMmYZ=cr4nLdq3efvUMQ@mail.gmail.com' \
--to=mathieu.poirier@linaro.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@infradead.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=eranian@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=vince@deater.net \
--cc=will.deacon@arm.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).