restricting counted/sampled events

restricting counted/sampled events

[Tony Jones]

I don't believe there is current support to do this,  but maybe I'm overlooking something?

I'd like to be able to restrict the pmu (or filter results) to report counting/sampling between two arbitrary code points,  such as a tracepoint or kprobe.

I believe it will require core perf changes and was curious on peoples thoughts?

Tony

Re: restricting counted/sampled events

[Andi Kleen]

Tony Jones <tonyj@suse.de> writes:

> I don't believe there is current support to do this,  but maybe I'm overlooking something?

It may be possible in systemtap, but not in the builtin tracers yes.
>
> I'd like to be able to restrict the pmu (or filter results) to report counting/sampling between two arbitrary code points,  such as a tracepoint or kprobe.
>
> I believe it will require core perf changes and was curious on peoples thoughts?

I'm not sure about messing with sampling (you can always filter that
later).

But able to collect PMU counter values are kprobes/tracepoints would be
fairly useful yes. It shouldn't be that difficult to do.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

Re: restricting counted/sampled events

[Arnaldo Carvalho de Melo]

Em Thu, Nov 12, 2015 at 10:18:02AM -0800, Tony Jones escreveu:

> I don't believe there is current support to do this,  but maybe I'm
> overlooking something?
 
> I'd like to be able to restrict the pmu (or filter results) to report
> counting/sampling between two arbitrary code points,  such as a
> tracepoint or kprobe.
 
> I believe it will require core perf changes and was curious on peoples
> thoughts?

Something like this:

https://lkml.org/lkml/2013/9/25/227

Jiri?

- Arnaldo

Re: restricting counted/sampled events

[Tony Jones]

On 11/12/2015 03:08 PM, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 12, 2015 at 10:18:02AM -0800, Tony Jones escreveu:
> 
>> I don't believe there is current support to do this,  but maybe I'm
>> overlooking something?
>  
>> I'd like to be able to restrict the pmu (or filter results) to report
>> counting/sampling between two arbitrary code points,  such as a
>> tracepoint or kprobe.
>  
>> I believe it will require core perf changes and was curious on peoples
>> thoughts?
> 
> Something like this:
> 
> https://lkml.org/lkml/2013/9/25/227

Yes, I'd not found that in my searching.   Thanks for the ptr.

Re: restricting counted/sampled events

[Jiri Olsa]

On Thu, Nov 12, 2015 at 08:08:07PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Nov 12, 2015 at 10:18:02AM -0800, Tony Jones escreveu:
> 
> > I don't believe there is current support to do this,  but maybe I'm
> > overlooking something?
>  
> > I'd like to be able to restrict the pmu (or filter results) to report
> > counting/sampling between two arbitrary code points,  such as a
> > tracepoint or kprobe.
>  
> > I believe it will require core perf changes and was curious on peoples
> > thoughts?
> 
> Something like this:
> 
> https://lkml.org/lkml/2013/9/25/227
> 
> Jiri?

yep.. sounds like toggling ;-) this code was put aside ATM

not sure it'll be ressurected soon, but I remember Stephane asked
me about that some time ago (CC-ed), maybe he has more info

jirka

Re: restricting counted/sampled events

[Tony Jones]

On 11/16/2015 12:59 AM, Jiri Olsa wrote:
> On Thu, Nov 12, 2015 at 08:08:07PM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Thu, Nov 12, 2015 at 10:18:02AM -0800, Tony Jones escreveu:
>>
>>> I don't believe there is current support to do this,  but maybe I'm
>>> overlooking something?
>>  
>>> I'd like to be able to restrict the pmu (or filter results) to report
>>> counting/sampling between two arbitrary code points,  such as a
>>> tracepoint or kprobe.
>>  
>>> I believe it will require core perf changes and was curious on peoples
>>> thoughts?
>>
>> Something like this:
>>
>> https://lkml.org/lkml/2013/9/25/227
>>
>> Jiri?
> 
> yep.. sounds like toggling ;-) this code was put aside ATM
> 
> not sure it'll be ressurected soon, but I remember Stephane asked
> me about that some time ago (CC-ed), maybe he has more info
> 
> jirka

If noone is currently working on it, I'd be interested in taking it over.

Tony