[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160425131013.GD3448@twins.programming.kicks-ass.net>
Date: Mon, 25 Apr 2016 15:10:13 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc: Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
vince@...ter.net, eranian@...gle.com,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>
Subject: Re: [PATCH v1 4/5] perf: Introduce address range filtering
On Fri, Apr 22, 2016 at 07:19:11PM +0300, Alexander Shishkin wrote:
> +static int perf_event_restart(struct perf_event *event)
> +{
> + struct stop_event_data sd = {
> + .event = event,
> + .restart = 1,
> + };
> + int ret = 0;
> +
> + do {
> + if (READ_ONCE(event->state) != PERF_EVENT_STATE_ACTIVE)
> + return 0;
> +
> + /* matches smp_wmb() in event_sched_in() */
> + smp_rmb();
> +
> + ret = cpu_function_call(READ_ONCE(event->oncpu),
> + __perf_event_stop, &sd);
> + } while (ret == -EAGAIN);
> +
> + return ret;
> +}
A few concerns with this;
- if I understand things right; this will loose a bit of trace when
people tickle the ioctl(), right? This might want a note of sorts,
- you need to handle event->oncpu == -1,
- can we race with an actual stop, and accidentally re-enable the
thing? If not, this might be a good place for a comment explaining
how.
Powered by blists - more mailing lists