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 15:15:50 -0700 [thread overview]
Message-ID: <CANLsYkz+j=vB+oZv_aJFQAq=J9pUCc2rvHTpBZKSLwLf4T7V5g@mail.gmail.com> (raw)
In-Reply-To: <CANLsYkz2iU2dUwshj8zYd1ix0yKtNYkMmYZ=cr4nLdq3efvUMQ@mail.gmail.com>
On 1 February 2017 at 14:33, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> )
>
> 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
Furthermore...
static const match_table_t if_tokens = {
{ IF_ACT_FILTER, "filter" },
{ IF_ACT_START, "start" },
{ IF_ACT_STOP, "stop" },
{ IF_SRC_FILE, "%u/%u@%s" },
{ IF_SRC_KERNEL, "%u/%u" },
{ IF_SRC_FILEADDR, "%u@%s" },
{ IF_SRC_KERNELADDR, "%u" },
{ IF_ACT_NONE, NULL },
};
Do we have two different syntax to specify the same behaviour?
For example we have:
--filter 'start 0x80082570/0x644'
and
--filter 'filter 0x80082570/0x644'
Both will end up with filter->filter == 1 and filter->range == 1.
The same will be true for:
--filter 'start 0x80082570'
and
--filter 'filter 0x80082570'
ends up with filter->filter == 1 and filter->range == 0.
>
>>
>> Regards,
>> --
>> Alex
next prev parent reply other threads:[~2017-02-01 22:15 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
2017-02-01 22:15 ` Mathieu Poirier [this message]
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='CANLsYkz+j=vB+oZv_aJFQAq=J9pUCc2rvHTpBZKSLwLf4T7V5g@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).