From: Michael Ellerman <michael@ellerman.id.au>
To: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
LKML <linux-kernel@vger.kernel.org>,
Stephane Eranian <eranian@google.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Linux PPC dev <linuxppc-dev@ozlabs.org>,
Michael Neuling <michael.neuling@au1.ibm.com>
Subject: Re: [PATCH V2 0/6] perf: New conditional branch filter
Date: Wed, 25 Sep 2013 12:19:45 +1000 [thread overview]
Message-ID: <1380075585.14938.4.camel@concordia> (raw)
In-Reply-To: <524006C4.3010006@linux.vnet.ibm.com>
On Mon, 2013-09-23 at 14:45 +0530, Anshuman Khandual wrote:
> On 09/21/2013 12:25 PM, Stephane Eranian wrote:
> > On Tue, Sep 10, 2013 at 4:06 AM, Michael Ellerman
> > <michael@ellerman.id.au> wrote:
> >> >
> >> > On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote:
> >>> > > This patchset is the re-spin of the original branch stack sampling
> >>> > > patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset
> >>> > > also enables SW based branch filtering support for PPC64 platforms which have
> >>> > > branch stack sampling support. With this new enablement, the branch filter support
> >>> > > for PPC64 platforms have been extended to include all these combinations discussed
> >>> > > below with a sample test application program.
> >> >
> >> > ...
> >> >
> >>> > > Mixed filters
> >>> > > -------------
> >>> > > (6) perf record -e branch-misses:u -j any_call,any_ret ./cprog
> >>> > > Error:
> >>> > > The perf.data file has no samples!
> >>> > >
> >>> > > NOTE: As expected. The HW filters all the branches which are calls and SW tries to find return
> >>> > > branches in that given set. Both the filters are mutually exclussive, so obviously no samples
> >>> > > found in the end profile.
> >> >
> >> > The semantics of multiple filters is not clear to me. It could be an OR,
> >> > or an AND. You have implemented AND, does that match existing behaviour
> >> > on x86 for example?
> >
> > The semantic on the API is OR. AND does not make sense: CALL & RETURN?
> > On x86, the HW filter is an OR (default: ALL, set bit to disable a
> > type). I suspect
> > it is similar on PPC.
>
> Given the situation as explained here, which semantic would be better for single
> HW and multiple SW filters. Accordingly validate_instruction() function will have
> to be re-implemented. But I believe OR-ing the SW filters will be preferable.
>
> (1) (HW_FILTER_1) && (SW_FILTER_1) && (SW_FILTER_2)
> or
> (2) (HW_FILTER_1) && (SW_FILTER_1 || SW_FILTER_2)
>
> Please let me know your inputs and suggestions on this. Thank you.
You need to implement the correct semantics, regardless of how the
hardware happens to work.
That means if multiple filters are specified you need to do all the
filtering in software.
cheers
next prev parent reply other threads:[~2013-09-25 2:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-30 4:24 [PATCH V2 0/6] perf: New conditional branch filter Anshuman Khandual
2013-08-30 4:24 ` [PATCH V2 1/6] perf: New conditional branch filter criteria in branch stack sampling Anshuman Khandual
2013-08-30 4:24 ` [PATCH V2 2/6] powerpc, perf: Enable conditional branch filter for POWER8 Anshuman Khandual
2013-08-30 4:24 ` [PATCH V2 3/6] perf, tool: Conditional branch filter 'cond' added to perf record Anshuman Khandual
2013-08-30 4:24 ` [PATCH V2 4/6] x86, perf: Add conditional branch filtering support Anshuman Khandual
2013-08-30 4:24 ` [PATCH V2 5/6] perf, documentation: Description for conditional branch filter Anshuman Khandual
2013-08-30 4:24 ` [PATCH V2 6/6] powerpc, perf: Enable SW filtering in branch stack sampling framework Anshuman Khandual
2013-08-30 11:48 ` [PATCH V2 0/6] perf: New conditional branch filter Stephane Eranian
2013-09-02 3:37 ` Anshuman Khandual
2013-09-21 6:41 ` Anshuman Khandual
2013-09-21 6:45 ` Anshuman Khandual
2013-09-10 2:06 ` Michael Ellerman
2013-09-10 3:52 ` Anshuman Khandual
2013-09-21 6:55 ` Stephane Eranian
2013-09-23 9:15 ` Anshuman Khandual
2013-09-25 2:19 ` Michael Ellerman [this message]
2013-09-25 6:15 ` Anshuman Khandual
2013-09-26 11:14 ` Stephane Eranian
2013-10-10 5:04 ` Anshuman Khandual
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=1380075585.14938.4.camel@concordia \
--to=michael@ellerman.id.au \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=khandual@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=michael.neuling@au1.ibm.com \
--cc=sukadev@linux.vnet.ibm.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).