On Fri, Dec 11, 2015 at 11:11:48AM -0700, Mathieu Poirier wrote:
> On 11 December 2015 at 06:36, Alexander Shishkin
> > /**
> > + * Instruction trace (ITRACE) filter
> > + */
> > +struct perf_itrace_filter {
> > + struct list_headentry;
> > + struct rcu_head rcu_head;
On Fri, Dec 11, 2015 at 07:13:10PM +0200, Alexander Shishkin wrote:
> Peter Zijlstra writes:
> > On second thought; we should not inherit the filters at all.
> >
> > We should always use event->parent (if exists) for filters. Otherwise
> > inherited events will get different filters if you change
On 11 December 2015 at 06:36, Alexander Shishkin
wrote:
> Many instruction trace pmus out there support address range-based
> filtering, which would, for example, generate trace data only for a
> given range of instruction addresses, which is useful for tracing
> individual functions, modules or l
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>> +static int
>> +perf_event_set_itrace_filter(struct perf_event *event, char *filter_str)
>> +{
>> +int ret = 0;
>> +
>> +/*
>> + * Since this is called in perf_ioctl() path, we're already h
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 04:28:54PM +0100, Peter Zijlstra wrote:
>> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>>
>> > @@ -9063,6 +9621,18 @@ inherit_event(struct perf_event *parent_event,
>> >get_ctx(child_ctx);
>> >
>> >/*
>> > + * C
On Fri, Dec 11, 2015 at 05:01:36PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 11, 2015 at 05:48:03PM +0200, Alexander Shishkin wrote:
>
> > > We can always call the validation thing, we must not call the program
> > > thing !ACTIVE is a clear and simple rule.
> >
> > Ah, but pmu::itrace_filter_se
On Fri, Dec 11, 2015 at 04:28:54PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>
> > @@ -9063,6 +9621,18 @@ inherit_event(struct perf_event *parent_event,
> > get_ctx(child_ctx);
> >
> > /*
> > +* Clone itrace filters from the pa
On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> +static int
> +perf_event_set_itrace_filter(struct perf_event *event, char *filter_str)
> +{
> + int ret = 0;
> +
> + /*
> + * Since this is called in perf_ioctl() path, we're already holding
> + * ctx::mutex.
>
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>> +static int __perf_event_itrace_filters_setup(void *info)
>> +{
>> +struct perf_event *event = info;
>> +int ret;
>> +
>> +if (READ_ONCE(event->state) != PERF_EVENT_STATE_ACTIVE)
>> +
On Fri, Dec 11, 2015 at 05:48:03PM +0200, Alexander Shishkin wrote:
> > We can always call the validation thing, we must not call the program
> > thing !ACTIVE is a clear and simple rule.
>
> Ah, but pmu::itrace_filter_setup() does not touch the hardware,
> pmu::start() does. The former keeps an
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 05:27:22PM +0200, Alexander Shishkin wrote:
>> Peter Zijlstra writes:
>>
>> > On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>> >> +static int perf_event_itrace_filters_setup(struct perf_event *event)
>> >> +{
>> >> + int ret
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>> +static int perf_event_itrace_filters_setup(struct perf_event *event)
>> +{
>> +int ret;
>> +
>> +/*
>> + * We can't use event_function_call() here, because that would
>> + * require ct
On Fri, Dec 11, 2015 at 05:27:22PM +0200, Alexander Shishkin wrote:
> Peter Zijlstra writes:
>
> > On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> >> +static int perf_event_itrace_filters_setup(struct perf_event *event)
> >> +{
> >> + int ret;
> >> +
> >> + /*
> >> + * W
On Fri, Dec 11, 2015 at 05:17:25PM +0200, Alexander Shishkin wrote:
> Peter Zijlstra writes:
>
> > On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> >> +static int __perf_event_itrace_filters_setup(void *info)
> >> +{
> >> + struct perf_event *event = info;
> >> + int ret;
>
On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> @@ -9063,6 +9621,18 @@ inherit_event(struct perf_event *parent_event,
> get_ctx(child_ctx);
>
> /*
> + * Clone itrace filters from the parent, if any
> + */
> + if (has_itrace_filter(child_event)) {
>
On Fri, Dec 11, 2015 at 04:02:36PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> > +static int perf_event_itrace_filters_setup(struct perf_event *event)
> > +{
> > + int ret;
> > +
> > + /*
> > +* We can't use event_function_call() here
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 02:23:36PM +, Mark Rutland wrote:
>> On Fri, Dec 11, 2015 at 03:02:01PM +0100, Peter Zijlstra wrote:
>> > On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>> >
>> > > The pmu driver interface basically adds an extra callback
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>> +static int __perf_event_itrace_filters_setup(void *info)
>> +{
>> +struct perf_event *event = info;
>> +int ret;
>> +
>> +if (READ_ONCE(event->state) != PERF_EVENT_STATE_ACTIVE)
>> +
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>> @@ -5921,6 +6010,8 @@ static void perf_event_comm_event(struct
>> perf_comm_event *comm_event)
>>
>> comm_event->event_id.header.size = sizeof(comm_event->event_id) + size;
>>
>> +if (com
On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> +/*
> + * Scan through mm's vmas and see if one of them matches the
> + * @filter; if so, adjust filter's address range.
> + * Called with mm::mmap_sem down for reading.
> + */
> +static int perf_itrace_filter_apply(struct perf_e
On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> @@ -559,6 +590,10 @@ struct perf_event {
>
> atomic_tevent_limit;
>
> + /* instruction trace filters */
> + struct list_headitrace_filters;
> + struct mutex
On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> @@ -5921,6 +6010,8 @@ static void perf_event_comm_event(struct
> perf_comm_event *comm_event)
>
> comm_event->event_id.header.size = sizeof(comm_event->event_id) + size;
>
> + if (comm_event->event_id.header.misc =
On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> +static int perf_event_itrace_filters_setup(struct perf_event *event)
> +{
> + int ret;
> +
> + /*
> + * We can't use event_function_call() here, because that would
> + * require ctx::mutex, but one of our calle
On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> +static int __perf_event_itrace_filters_setup(void *info)
> +{
> + struct perf_event *event = info;
> + int ret;
> +
> + if (READ_ONCE(event->state) != PERF_EVENT_STATE_ACTIVE)
> + return -EAGAIN;
> +
> +
On Fri, Dec 11, 2015 at 02:23:36PM +, Mark Rutland wrote:
> On Fri, Dec 11, 2015 at 03:02:01PM +0100, Peter Zijlstra wrote:
> > On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> >
> > > The pmu driver interface basically adds an extra callback to the
> > > pmu driver struct
On Fri, Dec 11, 2015 at 03:02:01PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>
> > The pmu driver interface basically adds an extra callback to the
> > pmu driver structure, which validates the filter configuration proposed
> > by the user a
Peter Zijlstra writes:
> On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
>
>> The pmu driver interface basically adds an extra callback to the
>> pmu driver structure, which validates the filter configuration proposed
>> by the user against what the hardware is actually capabl
On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote:
> The pmu driver interface basically adds an extra callback to the
> pmu driver structure, which validates the filter configuration proposed
> by the user against what the hardware is actually capable of doing
> and translates it
Many instruction trace pmus out there support address range-based
filtering, which would, for example, generate trace data only for a
given range of instruction addresses, which is useful for tracing
individual functions, modules or libraries.
This patch introduces the interface for userspace to s
29 matches
Mail list logo
