All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: rostedt <rostedt@goodmis.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Perf: event wakeup discards sched_waking events
Date: Mon, 14 Jan 2019 16:36:59 -0500 (EST)	[thread overview]
Message-ID: <615183542.671.1547501819850.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <20190114130957.GA10486@hirez.programming.kicks-ass.net>

----- On Jan 14, 2019, at 8:09 AM, Peter Zijlstra peterz@infradead.org wrote:

> 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?

Considering that perf tracing code has side-effects that generate additional
events, it's indeed best not to trace them, otherwise you indeed end up with
tail recursion.

Can ftrace end up in the same situation through rb_wake_up_waiters() ? I suspect
the tail recursion would be hard to trigger if the wakeup only happens once per
page though, unless the events generated end up filling up a page.

FWIW, LTTng avoids this entire issue by using a timer-based polling mechanism
to ensure the tracing code does not call into the scheduler wakeup.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

  reply	other threads:[~2019-01-14 21:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  1:38 Possible use of RCU while in extended QS: idle vs RCU read-side in interrupt vs rcu_eqs_exit Mathieu Desnoyers
2019-01-10  4:13 ` Paul E. McKenney
2019-01-10  6:30   ` Mathieu Desnoyers
2019-01-10 14:19     ` Paul E. McKenney
2019-01-10 16:08 ` Steven Rostedt
2019-01-10 16:44   ` Mathieu Desnoyers
2019-01-10 17:11     ` Mathieu Desnoyers
2019-01-10 17:23       ` Steven Rostedt
2019-01-10 17:25       ` Mathieu Desnoyers
2019-01-10 17:45         ` Perf: event wakeup discards sched_waking events Mathieu Desnoyers
2019-01-14 13:09           ` Peter Zijlstra
2019-01-14 21:36             ` Mathieu Desnoyers [this message]
2019-01-14 22:04               ` Steven Rostedt
2019-01-14 22:31                 ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=615183542.671.1547501819850.JavaMail.zimbra@efficios.com \
    --to=mathieu.desnoyers@efficios.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.