On 09/26/2013 04:44 PM, Stephane Eranian wrote: > So you are saying that the HW filter is exclusive. That seems odd. But > I think it is > because of the choices is ANY. ANY covers all the types of branches. Therefore > it does not make a difference whether you add COND or not. And > vice-versa, if you > set COND, you need to disable ANY. I bet if you add other filters such > as CALL, RETURN, > then you could OR them and say: I want RETURN or CALLS. > > But that's okay. The API operates in OR mode but if the HW does not > support it, you > can check the mask and reject if more than one type is set. That is > arch-specific code. > The alternative, if to only capture ANY and emulate the filter in SW. > This will work, of > course. But the downside, is that you lose the way to appreciate how > many, for instance, > COND branches you sampled out of the total number of COND branches > retired. Unless > you can count COND branches separately.
Hey Stephane, Thanks for your reply. I am working on a solution where PMU will process all the requested branch filters in HW only if it can filter all of them in an OR manner else it will just leave the entire thing upto the SW to process and do no filtering itself. This implies that branch filtering will either happen completely in HW or completely in SW and never in a mixed manner. This way it will conform to the OR mode defined in the API. I will post the revised patch set soon. Regards Anshuman _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
