Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 9 Mar 2020 15:25:53 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To:     rostedt <rostedt@goodmis.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        paulmck <paulmck@kernel.org>,
        "Joel Fernandes, Google" <joel@joelfernandes.org>,
        Frederic Weisbecker <frederic@kernel.org>
Message-ID: <1421454673.21890.1583781953778.JavaMail.zimbra@efficios.com>
In-Reply-To: <20200309150940.26730dee@gandalf.local.home>
References: <87mu8p797b.fsf@nanos.tec.linutronix.de> <1403546357.21810.1583779060302.JavaMail.zimbra@efficios.com> <20200309144427.0ce0eabc@gandalf.local.home> <1851876075.21840.1583779960064.JavaMail.zimbra@efficios.com> <20200309150940.26730dee@gandalf.local.home>
Subject: Re: Instrumentation and RCU
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Topic: Instrumentation and RCU
Thread-Index: i3rbokcdGHS5QSdW4VDvsuVnJMyLcQ==
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

----- On Mar 9, 2020, at 3:09 PM, rostedt rostedt@goodmis.org wrote:

> On Mon, 9 Mar 2020 14:52:40 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
>> And when I say "go back to plain RCU", I really mean removing use of SRCU
>> from the tracepoints until we have other purposes for it (e.g. taking
>> faults within specific tracepoint probes such as syscall enter/exit).
> 
> Actually, with both you and Alexei talking about having a sleeping
> tracepoint callback, where we can add a can sleep check (but not in the
> DO_TRACE macro, I would think that registered sleeping callbacks would be
> its own callback), I would think we do not want to remove the SRCU usage.

Whether we keep it or add it back later when needed should not make much
difference.

In any case, considering that overhead which motivated use of SRCU for the rcuidle
case could instead be handled by using is_rcu_watching() and normal RCU, I would
prefer removing it from the rcuidle tracepoints for now, and add it back when we
add a new kind of "sleepable" tracepoints later on.

Thanks,

Mathieu

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