[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190114130957.GA10486@hirez.programming.kicks-ass.net>
Date: Mon, 14 Jan 2019 14:09:57 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: rostedt <rostedt@...dmis.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: Perf: event wakeup discards sched_waking events
On Thu, Jan 10, 2019 at 12:45:27PM -0500, Mathieu Desnoyers wrote:
> static void perf_pending_event(struct irq_work *entry)
> {
> struct perf_event *event = container_of(entry,
> struct perf_event, pending);
> int rctx;
>
> rctx = perf_swevent_get_recursion_context();
> /*
> * If we 'fail' here, that's OK, it means recursion is already disabled
> * and we won't recurse 'further'.
> */
>
> if (event->pending_disable) {
> event->pending_disable = 0;
> perf_event_disable_local(event);
> }
>
> if (event->pending_wakeup) {
> event->pending_wakeup = 0;
> perf_event_wakeup(event);
> }
>
> if (rctx >= 0)
> perf_swevent_put_recursion_context(rctx);
> }
>
> One side-effect of perf_event_wakeup() is to generate a sched_waking
> event. But I suspect it won't be traced by perf because it is invoked before
> putting the recursion context.
>
> Is there a reason why the wakeup is done before putting the recursion
> context ?
d525211f9d1b ("perf: Fix irq_work 'tail' recursion")
If we were to allow perf_event_wakeup() to generate its tracepoint, we'd
be back to square #1, no?
Powered by blists - more mailing lists