Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp6978791ybf; Fri, 6 Mar 2020 08:05:51 -0800 (PST) X-Google-Smtp-Source: ADFU+vvfwuWr+1Se9fA4Wh6VO89NSyL8enNHnV3wpGU3hO97sP+NG049WRsgQEsVoZDJqeA4BAEJ X-Received: by 2002:aca:aa53:: with SMTP id t80mr3116630oie.161.1583510751816; Fri, 06 Mar 2020 08:05:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583510751; cv=none; d=google.com; s=arc-20160816; b=KdViLnZMcHFDBexr6jzECLKJSO7MgmAbESXBDNyH/ug2zoQvygbz5xQf+vRdHCm5y6 vW4BudeBbcNOpAjrWJ6emSQpUUBLWuxMZfxV7leerLKE8KsvMy1staGMctm7HmkfLQOW HnxNoW3WxJ3HGmF4JKGsFBffpNtflb+oh0hrbljuU/dkozxIinG276+0u6UdDj60oNwn GzVFiShp9xjDjhlW2qxutaObLyinbbJt/s/5/CJVmxBJ767uRhALQTh6O4/K6G13SrLC /ueI6IUk3kPOSNwORcA0+OUCIvQOo7U/x8iKP1505br/wf+bemI/m9pxL9LFPwt7HQhg 0GFw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:thread-index:thread-topic :content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:dkim-signature:dkim-filter; bh=6j5JaL7Ua/h0tRIOesi8OT8YjRo+RrU/0uZVVdHVaUc=; b=Je3t7e3Q2NPo12hyBg5lxCj+RM65g6kiU0Yk0i2Nh3Y1dAWY3PwnHgx9iqDFllyQEZ pf/89hJg8ZBaU4K1gyE3BJR0ijDsStEjdp25SSJZPCfvZsUqRM9k/Ukaj7jZSQVhQLp4 hUFOrkXAdO1MBEZ6bXFGAqVZL1KZ9+M9t4aZwSNrjntsOE3urfYB7oHX5YoDcI79YW4T 7mKaa+OzdKJXDfNIUO8Yx6hJSMlgCBBwSGuUmb+jN0QW941txG+3UMocw25OxtU+B6Mz FBOjkL3HfkydFXdoCocJ+bu1SLPGm1fZu7spPRbtLF6BY1rNImd++ZX/ttqHzYz/gh2q +u3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=WtwakTcI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g24si1939306otn.296.2020.03.06.08.05.30; Fri, 06 Mar 2020 08:05:51 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=default header.b=WtwakTcI; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727126AbgCFQEa (ORCPT + 99 others); Fri, 6 Mar 2020 11:04:30 -0500 Received: from mail.efficios.com ([167.114.26.124]:44462 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbgCFQEa (ORCPT ); Fri, 6 Mar 2020 11:04:30 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id C1CAA256FB7; Fri, 6 Mar 2020 11:04:28 -0500 (EST) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dxrs-FQVPtJQ; Fri, 6 Mar 2020 11:04:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 595EC256DF7; Fri, 6 Mar 2020 11:04:28 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 595EC256DF7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=efficios.com; s=default; t=1583510668; bh=6j5JaL7Ua/h0tRIOesi8OT8YjRo+RrU/0uZVVdHVaUc=; h=Date:From:To:Message-ID:MIME-Version; b=WtwakTcInK9Ow6gYVMTNvKU9/piqdY3nhzkNHs1hUwILaWj7bES3pHrnTDvxDYQPA nt+z6IPj7xtrrQkQsPYFSwNmsx5PtiIpEMbCuXYutme4/CRamTY3xZ/FH5F+JL3YTF ywOwPNgw4KgJ+opE/39MgZ2RLinIUrZKjTEmHfLFDJBUrUj6XxqAH9LSQLTdHxvmiX /B0SCzLgKWUpACIEbU7Jh8Fsf8BK/cBubt34IayVmWwBWaQLVKW32OgNuwwltpiXFH l7sCK0Xq4h2sNFe9qCW0O9HD4BDn+AC+XiHEKB6shS4ZAYSy0+r6ZWUwzfGd7KkdMW 2PaejpLRwFf/Q== X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TvwxhIRj8G-2; Fri, 6 Mar 2020 11:04:28 -0500 (EST) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 4587D257286; Fri, 6 Mar 2020 11:04:28 -0500 (EST) Date: Fri, 6 Mar 2020 11:04:28 -0500 (EST) From: Mathieu Desnoyers To: Alexei Starovoitov Cc: Peter Zijlstra , linux-kernel , linux-arch , rostedt , Ingo Molnar , "Joel Fernandes, Google" , Greg Kroah-Hartman , "Gustavo A. R. Silva" , Thomas Gleixner , paulmck , Josh Triplett , Lai Jiangshan , Andy Lutomirski , Tony Luck , Frederic Weisbecker , dan carpenter , Masami Hiramatsu Message-ID: <1896740806.20220.1583510668164.JavaMail.zimbra@efficios.com> In-Reply-To: References: <20200221133416.777099322@infradead.org> <20200221134216.051596115@infradead.org> <20200306104335.GF3348@worktop.programming.kicks-ass.net> <20200306113135.GA8787@worktop.programming.kicks-ass.net> Subject: Re: [PATCH v4 16/27] tracing: Remove regular RCU context for _rcuidle tracepoints (again) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_3901 (ZimbraWebClient - FF73 (Linux)/8.8.15_GA_3895) Thread-Topic: tracing: Remove regular RCU context for _rcuidle tracepoints (again) Thread-Index: EGOI/yncDm66QywVpmO/bDrskNz8Mw== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Mar 6, 2020, at 10:51 AM, Alexei Starovoitov alexei.starovoitov@gmail.com wrote: > On Fri, Mar 6, 2020 at 3:31 AM Peter Zijlstra wrote: >> >> On Fri, Mar 06, 2020 at 11:43:35AM +0100, Peter Zijlstra wrote: >> > On Fri, Feb 21, 2020 at 02:34:32PM +0100, Peter Zijlstra wrote: >> > > Effectively revert commit 865e63b04e9b2 ("tracing: Add back in >> > > rcu_irq_enter/exit_irqson() for rcuidle tracepoints") now that we've >> > > taught perf how to deal with not having an RCU context provided. >> > > >> > > Signed-off-by: Peter Zijlstra (Intel) >> > > Reviewed-by: Steven Rostedt (VMware) >> > > --- >> > > include/linux/tracepoint.h | 8 ++------ >> > > 1 file changed, 2 insertions(+), 6 deletions(-) >> > > >> > > --- a/include/linux/tracepoint.h >> > > +++ b/include/linux/tracepoint.h >> > > @@ -179,10 +179,8 @@ static inline struct tracepoint *tracepo >> > > * For rcuidle callers, use srcu since sched-rcu \ >> > > * doesn't work from the idle path. \ >> > > */ \ >> > > - if (rcuidle) { \ >> > > + if (rcuidle) \ >> > > __idx = srcu_read_lock_notrace(&tracepoint_srcu);\ >> > > - rcu_irq_enter_irqsave(); \ >> > > - } \ >> > > \ >> > > it_func_ptr = rcu_dereference_raw((tp)->funcs); \ >> > > \ >> > > @@ -194,10 +192,8 @@ static inline struct tracepoint *tracepo >> > > } while ((++it_func_ptr)->func); \ >> > > } \ >> > > \ >> > > - if (rcuidle) { \ >> > > - rcu_irq_exit_irqsave(); \ >> > > + if (rcuidle) \ >> > > srcu_read_unlock_notrace(&tracepoint_srcu, __idx);\ >> > > - } \ >> > > \ >> > > preempt_enable_notrace(); \ >> > > } while (0) >> > >> > So what happens when BPF registers for these tracepoints? BPF very much >> > wants RCU on AFAIU. >> >> I suspect we needs something like this... >> >> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c >> index a2f15222f205..67a39dbce0ce 100644 >> --- a/kernel/trace/bpf_trace.c >> +++ b/kernel/trace/bpf_trace.c >> @@ -1475,11 +1475,13 @@ void bpf_put_raw_tracepoint(struct bpf_raw_event_map >> *btp) >> static __always_inline >> void __bpf_trace_run(struct bpf_prog *prog, u64 *args) >> { >> + int rcu_flags = trace_rcu_enter(); >> rcu_read_lock(); >> preempt_disable(); >> (void) BPF_PROG_RUN(prog, args); >> preempt_enable(); >> rcu_read_unlock(); >> + trace_rcu_exit(rcu_flags); > > One big NACK. > I will not slowdown 99% of cases because of one dumb user. > Absolutely no way. If we care about not adding those extra branches on the fast-path, there is an alternative way to do things: BPF could provide two distinct probe callbacks, one meant for rcuidle tracepoints (which would have the trace_rcu_enter/exit), and the other for the for 99% of the other callsites which have RCU watching. I would recommend performing benchmarks justifying the choice of one approach over the other though. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com