Re: [PATCH V2 0/6] perf: New conditional branch filter

[Anshuman Khandual]

On 09/25/2013 07:49 AM, Michael Ellerman wrote:
> 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@xxxxxxxxxxxxxx> 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.

Hello Stephane,

I looked at the X86 code on branch filtering implementation.

(1) During event creation intel_pmu_hw_config calls intel_pmu_setup_lbr_filter when LBR sampling
    is required, intel_pmu_setup_lbr_filter calls these two functions 

	(a) intel_pmu_setup_sw_lbr_filter

	"event->hw.branch_reg.reg" contains all the SW filter masks which can be
	supported for the user requested filters event->attr.branch_sample_type (even
	if some of them could implemented in PMU HW)

	(b) intel_pmu_setup_hw_lbr_filter (when HW filtering is present)

	"event->hw.branch_reg.config" contains all the PMU HW filter masks corresponding
	to the requested filters in event->attr.branch_sample_type. One point to note
	here is that if the user has requested for some branch filter which is not supported
	in the HW LBR filter, the event creation request is rejected with EOPNOTSUPP. This
	not true for the filters which can be ignored in the PMU.

(2) When the event is enabled in the PMU

	(a) cpuc->lbr_sel->config gets into the HW register to enable the filtering of branches
	which was determined in the function intel_pmu_setup_hw_lbr_filter. 

(3) After the IRQ happened, intel_pmu_lbr_read reads all the entries from the LBR  HW and then
    applies the filter in the function intel_pmu_lbr_filter.

	(a) intel_pmu_lbr_filter functions take into account cpuc->br_sel (which is nothing but
	event->hw.branch_reg.reg as determined in the function intel_pmu_setup_sw_lbr_filter)
	which contains the entire branch filter request set in terms applicable SW filter. Here
	the semantic is OR when we look at from SW filter implementation point of view.

   BUT what branch record set we are working on right now ? A set which was captured with LBR HW
   with cpuc->lbr_sel->config filters enabled on it. So to me the X86 implementation of the semantics
   look something like this.
	
	A - Branch filter set requested by the user
	B - Subset of A which can be supported in HW
	C - Subset of A which can be supported in SW

	(B) && (C) 

	NOTE: Individual filters are OR-ed inside both B and C sets.

So here the semantics is not a true OR. This is my understanding till now which may be wrong. Please
help me understand if the semantics is something otherwise than what is explained above.

In POWER8 because we cannot OR individual HW PMU supported filters, till now the semantics looked a bit odd.
But as Michael has pointed out here that if there are multiple branch filter requests implement all of them
in SW. Only in case where the user requests for an individual filter and if it happen to be supported in HW
PMU, we will use the PMU filters.

Regards
Anshuman

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/