Received: by 10.192.165.148 with SMTP id m20csp3579429imm; Mon, 7 May 2018 14:58:12 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr/zwiOm82R7hji/DlCVVv6E3oFRoqDfHE7087uy88zYSxjK3BiKQEiGzbi74Tw2/JRQ6J3 X-Received: by 2002:a17:902:584:: with SMTP id f4-v6mr38346817plf.290.1525730292392; Mon, 07 May 2018 14:58:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525730292; cv=none; d=google.com; s=arc-20160816; b=Gg1QxEood1C+eIYxECRF3NUIGeODCIUW+rk889yFW/om898l/NZL3FSJb/vQ2SDjUT nddH9fz4TdF5qwu0W7IZkXPQ9SUZvTsgaRQDki725NwVoZEIYs0EJjaGPDduK2FuHZqx y4KEjC9r9Sl4DZ0AKbDGSnx1HrOlRAgZPvln51ZMCT6S1XIb6NcoavopfCcI0svIHmv3 KWvzkks+ZIjrqwxspKMGuimiTyenrUO3MXRpHBG3JMDtjV3t6H7I7HmeEtwEhKuuBRcU EcVBTgKfTwprROw1DEZ4/OrkKBmJp3OXkJNXYSJEoZm/7yLhhvJm+5XfTkFoZ3vIJEta MEjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:subject:cc:to :from:date:arc-authentication-results; bh=1/MzaijcSh4qMLxnKhA/7mZp++/r0UjTCzuA/UUgyl0=; b=KLryvKZxAlWl3aHsKOypvN7ahgRC/XbAgLGfOgcZ7IcdvxvjKMcr1xTxrZsyQxzt5r zRUVxxNJl6Lwf8TqB9IUYKr5jP3ly96hTQwoiz2Or+EWDqDRj0luRqM4yDNuPPeguwqY W1V+3d3nv3sIX/vqueKQhpafmKzExbsGkALoOnF7VpRK0cgxhN3/nsP1vaKNs6pDmqdd BHdXHd4lLI20Tw88/c321Or5V98e40jricq49sik8jP3TM6dTv9VVfqjlk5+s4RwfLm9 OTnVmW3kAHlmrycmQsMcfpiH+yH+nbgNzuS6j8s0XfHHbepUW8B2uRltzmFXC0N1eWg7 EAZw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r39-v6si22773538pld.249.2018.05.07.14.57.56; Mon, 07 May 2018 14:58:12 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753084AbeEGVy1 (ORCPT + 99 others); Mon, 7 May 2018 17:54:27 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36694 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752846AbeEGVy0 (ORCPT ); Mon, 7 May 2018 17:54:26 -0400 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w47LqrZG021074 for ; Mon, 7 May 2018 17:54:25 -0400 Received: from e17.ny.us.ibm.com (e17.ny.us.ibm.com [129.33.205.207]) by mx0b-001b2d01.pphosted.com with ESMTP id 2htwcvce7f-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 07 May 2018 17:54:25 -0400 Received: from localhost by e17.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 7 May 2018 17:54:25 -0400 Received: from b01cxnp23032.gho.pok.ibm.com (9.57.198.27) by e17.ny.us.ibm.com (146.89.104.204) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 7 May 2018 17:54:20 -0400 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w47LsJUc48365724; Mon, 7 May 2018 21:54:19 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CEFDBB204E; Mon, 7 May 2018 18:56:18 -0400 (EDT) Received: from paulmck-ThinkPad-W541 (unknown [9.70.82.108]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP id 85DC9B204D; Mon, 7 May 2018 18:56:18 -0400 (EDT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 30F5816C2981; Mon, 7 May 2018 14:55:45 -0700 (PDT) Date: Mon, 7 May 2018 14:55:45 -0700 From: "Paul E. McKenney" To: Joel Fernandes Cc: Joel Fernandes , linux-kernel@vger.kernel.org, Steven Rostedt , Peter Zilstra , Ingo Molnar , Mathieu Desnoyers , Tom Zanussi , Namhyung Kim , Thomas Glexiner , Boqun Feng , Frederic Weisbecker , Randy Dunlap , Masami Hiramatsu , Fenguang Wu , Baohong Liu , Vedang Patel , kernel-team@android.com Subject: Re: [PATCH RFC v6 4/5] tracepoint: Make rcuidle tracepoint callers use SRCU Reply-To: paulmck@linux.vnet.ibm.com References: <20180507204143.13061-1-joelaf@google.com> <20180507204143.13061-5-joelaf@google.com> <20180507210801.GZ26088@linux.vnet.ibm.com> <20180507214514.GA13787@joelaf.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180507214514.GA13787@joelaf.mtv.corp.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18050721-0040-0000-0000-00000427F1D5 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008989; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000258; SDB=6.01028992; UDB=6.00525758; IPR=6.00808126; MB=3.00020980; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-07 21:54:24 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18050721-0041-0000-0000-0000082DFE41 Message-Id: <20180507215545.GA26088@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-07_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805070214 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 07, 2018 at 02:45:14PM -0700, Joel Fernandes wrote: > On Mon, May 07, 2018 at 02:08:01PM -0700, Paul E. McKenney wrote: > > On Mon, May 07, 2018 at 01:41:42PM -0700, Joel Fernandes wrote: > > > From: "Joel Fernandes (Google)" > > > > > > In recent tests with IRQ on/off tracepoints, a large performance > > > overhead ~10% is noticed when running hackbench. This is root caused to > > > calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the > > > tracepoint code. Following a long discussion on the list [1] about this, > > > we concluded that srcu is a better alternative for use during rcu idle. > > > Although it does involve extra barriers, its lighter than the sched-rcu > > > version which has to do additional RCU calls to notify RCU idle about > > > entry into RCU sections. > > > > > > In this patch, we change the underlying implementation of the > > > trace_*_rcuidle API to use SRCU. This has shown to improve performance > > > alot for the high frequency irq enable/disable tracepoints. > [...] > >> Signed-off-by: Joel Fernandes (Google) > > > --- > > > include/linux/tracepoint.h | 46 +++++++++++++++++++++++++++++++------- > > > kernel/tracepoint.c | 15 ++++++++++++- > > > 2 files changed, 52 insertions(+), 9 deletions(-) > > > > > > diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h > > > index c94f466d57ef..f56f290cf8eb 100644 > > > --- a/include/linux/tracepoint.h > > > +++ b/include/linux/tracepoint.h > > > @@ -15,6 +15,7 @@ > > > */ > > > > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -33,6 +34,8 @@ struct trace_eval_map { > > > > > > #define TRACEPOINT_DEFAULT_PRIO 10 > > > > > > +extern struct srcu_struct tracepoint_srcu; > > > + > > > extern int > > > tracepoint_probe_register(struct tracepoint *tp, void *probe, void *data); > > > extern int > > > @@ -77,6 +80,9 @@ int unregister_tracepoint_module_notifier(struct notifier_block *nb) > > > */ > > > static inline void tracepoint_synchronize_unregister(void) > > > { > > > +#ifdef CONFIG_TRACEPOINTS > > > + synchronize_srcu(&tracepoint_srcu); > > > +#endif > > > synchronize_sched(); > > > } > > > > > > @@ -129,18 +135,38 @@ extern void syscall_unregfunc(void); > > > * as "(void *, void)". The DECLARE_TRACE_NOARGS() will pass in just > > > * "void *data", where as the DECLARE_TRACE() will pass in "void *data, proto". > > > */ > > > -#define __DO_TRACE(tp, proto, args, cond, rcucheck) \ > > > +#define __DO_TRACE(tp, proto, args, cond, rcuidle) \ > > > do { \ > > > struct tracepoint_func *it_func_ptr; \ > > > void *it_func; \ > > > void *__data; \ > > > + int __maybe_unused idx = 0; \ > > > \ > > > if (!(cond)) \ > > > return; \ > > > - if (rcucheck) \ > > > - rcu_irq_enter_irqson(); \ > > > - rcu_read_lock_sched_notrace(); \ > > > - it_func_ptr = rcu_dereference_sched((tp)->funcs); \ > > > + \ > > > + /* \ > > > + * For rcuidle callers, use srcu since sched-rcu \ > > > + * doesn't work from the idle path. \ > > > + */ \ > > > + if (rcuidle) { \ > > > + if (in_nmi()) { \ > > > + WARN_ON_ONCE(1); \ > > > + return; /* no srcu from nmi */ \ > > > + } \ > > > + \ > > > + idx = srcu_read_lock_notrace(&tracepoint_srcu); \ > > > + it_func_ptr = \ > > > + srcu_dereference_notrace((tp)->funcs, \ > > > + &tracepoint_srcu); \ > > > + /* To keep it consistent with !rcuidle path */ \ > > > + preempt_disable_notrace(); \ > > > + } else { \ > > > + rcu_read_lock_sched_notrace(); \ > > > + it_func_ptr = \ > > > + rcu_dereference_sched((tp)->funcs); \ > > > + } \ > > > + \ > > > if (it_func_ptr) { \ > > > do { \ > > > it_func = (it_func_ptr)->func; \ > > > @@ -148,9 +174,13 @@ extern void syscall_unregfunc(void); > > > ((void(*)(proto))(it_func))(args); \ > > > } while ((++it_func_ptr)->func); \ > > > } \ > > > - rcu_read_unlock_sched_notrace(); \ > > > - if (rcucheck) \ > > > - rcu_irq_exit_irqson(); \ > > > + \ > > > + if (rcuidle) { \ > > > > Don't we also need an in_nmi() check here in order to avoid unbalanced > > srcu_read_unlock_notrace() calls? > > The in_nmi() in the lock path should take care of making sure its balanced. > > The diff the way its formatted appears confusing as Mathieu pointed. Ah, right, I was for some reason thinking that the two hunks of the diff were two separate macros. Apologies for my confusion! Thanx, Paul