Received: by 10.192.165.148 with SMTP id m20csp3655616imm; Mon, 7 May 2018 16:38:24 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr9ZmoE9Fi5fjMQlOI2vaxPqdYYKlUiksGkgFermMt+RzFFPMNEjQo5QHOzHX/MM0nn3top X-Received: by 10.98.149.21 with SMTP id p21mr37872426pfd.62.1525736304663; Mon, 07 May 2018 16:38:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525736304; cv=none; d=google.com; s=arc-20160816; b=G5XPq4YjMuyKmEyhxC+a7NtFGmgqIUTwus3PgMd06XmzSgoXXD3rPRd7PLVHyD+ZT/ zr8uNpYKLRBJ3zt01/oOHAOlOnqoOouvHHgQt2MQiQeW2DBe5spp+I/vyWGNkPMVgV0i 1Ne74j0OffIsLDdgIqHQfSXunXUzqx+cv7OHyMPTGZ1taqtm2GAwrflgCEorZt6ey1OK qr5eY6YR7dZWXWPgEMkXDAl6BqfdMRE11eT+ceoq8XJs9JfCMi1brn3PfUsxsi212ZlR 4dLPGYIVBR/7Bf3ZHt/XvqDd2924scMyA2UiSyledRCXmY/T7qQKcPHOXCGB7J2hYM87 Rwrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:dkim-signature:arc-authentication-results; bh=midMZMlSSZxZdboVYXRuLG1ewW2x6rHC52c4Ln/z4Qk=; b=j427VN5soKQepH9We0N5IJg2RW8h8JMYwSMBiLgq+X8Frhbn84lAaCo9BuCVCuAm9i 5eLR+YKEz7Jt+mnCN+8jumqRAbze/LZNBPLWNVsLmTpVRK5A/eVRefgRR0yH4vduAqYo igFZ2qvbQtHSEr9LA+91RtDoPrK3HkQa5nyIz3W7fdjAXSUmE/VKe7dOTagMo03V6vdq OXwYTDucseeNampPFtLBAZIew1W5zdYs0YbsEOKFtHRXsKWoqhdCXpxIKYAESnYtbP4o tkmFP3rjJZRLPhfQiPYAxs9yo2vweHK9TmZymX7MuVPwCjjJA2Co/AlLhhhXU86ZS6qU z2JA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ueDSwJMZ; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9-v6si22961254plf.283.2018.05.07.16.38.10; Mon, 07 May 2018 16:38:24 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=ueDSwJMZ; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753416AbeEGXhy (ORCPT + 99 others); Mon, 7 May 2018 19:37:54 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:41881 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752920AbeEGXhw (ORCPT ); Mon, 7 May 2018 19:37:52 -0400 Received: by mail-pg0-f67.google.com with SMTP id m21-v6so20334988pgv.8 for ; Mon, 07 May 2018 16:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:cc:from:message-id; bh=midMZMlSSZxZdboVYXRuLG1ewW2x6rHC52c4Ln/z4Qk=; b=ueDSwJMZJ6/6IGi20OSos1VOhvl//ReM7enLJrcE8f9muPzeGHJM1Qr0j/zKUp0a2T /S1GmEQH6+7w4+7YFdXXjIfoAyxpbbPXMyykYAAIdAGSkj2zpivAl/Qs4PPeKv8+jug7 98nGbqTR2mRviilsPP4PkMExQZu50chX9e7Dn0N5iDEt633AUR3D/bDkG81N4IZw8E/3 j//8SJ4RjHkjaqKjLWS7cUoVWbIKWN+5KBb0Pd7xhhKKXzpbdmZescBMd+zQ5SJUtutv kykX2b1tr2AcN5KtHyAJKhSczis3i3ozfziV2IcCo0+XNcYMN4LExPxZaCK+XM3+P97x /PtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=midMZMlSSZxZdboVYXRuLG1ewW2x6rHC52c4Ln/z4Qk=; b=NUUJ9fpJRpww1V2t5GR3W2cxb0n8ZHn00jUmb8M7Mxjq2t/J3gZSrONbAc6ndSNbd7 1+so6xReQUokag5DxugQKxb/eIDxOaPfY/eoH3qHAuHdI01gxWYqJXH/eA8szbPgm8Df pvu3mcsu5vpoJpxjBzZ09ZAT1Hk2FsCWiwaigKkFrydVXBfHvlC6HEJ1eqy3Usy4UDdA fSbU7RKyT4HrdIxVlSbcPi780PD9B5F+LxoAZnROVRtdz3HVIIFZk82UbgVec/iuvjLi UqISKJuEXIVBszep7sMJ1dPfG1XusynX+ViDdnpA4jH94+b9PhwbWmaqdozH/eAm2yhy lr+Q== X-Gm-Message-State: ALQs6tCM9EUTJ1fPC+Jd4v5RePfBRDLxitN5J4vvWfoweeJ1y5B9PMN1 DTytmX4NeGHxKNvAIt3eLkM= X-Received: by 2002:a63:69c3:: with SMTP id e186-v6mr30871246pgc.353.1525736271919; Mon, 07 May 2018 16:37:51 -0700 (PDT) Received: from [192.168.0.113] ([24.6.205.35]) by smtp.gmail.com with ESMTPSA id u9sm7214351pfi.60.2018.05.07.16.37.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 16:37:51 -0700 (PDT) Date: Mon, 07 May 2018 16:37:45 -0700 User-Agent: K-9 Mail for Android In-Reply-To: <20180507215545.GA26088@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> <20180507215545.GA26088@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH RFC v6 4/5] tracepoint: Make rcuidle tracepoint callers use SRCU To: paulmck@linux.vnet.ibm.com, "Paul E. McKenney" , 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 From: Joel Fernandes Message-ID: <700CDAD4-15FB-4AE7-868C-AE01B1F9FD62@gmail.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On May 7, 2018 2:55:45 PM PDT, "Paul E=2E McKenney" wrote: >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=2E McKenney wrote: >> > On Mon, May 07, 2018 at 01:41:42PM -0700, Joel Fernandes wrote: >> > > From: "Joel Fernandes (Google)" >> > >=20 >> > > In recent tests with IRQ on/off tracepoints, a large performance >> > > overhead ~10% is noticed when running hackbench=2E This is root >caused to >> > > calls to rcu_irq_enter_irqson and rcu_irq_exit_irqson from the >> > > tracepoint code=2E Following a long discussion on the list [1] >about this, >> > > we concluded that srcu is a better alternative for use during rcu >idle=2E >> > > 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=2E >> > >=20 >> > > In this patch, we change the underlying implementation of the >> > > trace_*_rcuidle API to use SRCU=2E This has shown to improve >performance >> > > alot for the high frequency irq enable/disable tracepoints=2E >> [=2E=2E=2E] >> >> Signed-off-by: Joel Fernandes (Google) >> > > --- >> > > include/linux/tracepoint=2Eh | 46 >+++++++++++++++++++++++++++++++------- >> > > kernel/tracepoint=2Ec | 15 ++++++++++++- >> > > 2 files changed, 52 insertions(+), 9 deletions(-) >> > >=20 >> > > diff --git a/include/linux/tracepoint=2Eh >b/include/linux/tracepoint=2Eh >> > > index c94f466d57ef=2E=2Ef56f290cf8eb 100644 >> > > --- a/include/linux/tracepoint=2Eh >> > > +++ b/include/linux/tracepoint=2Eh >> > > @@ -15,6 +15,7 @@ >> > > */ >> > >=20 >> > > #include >> > > +#include >> > > #include >> > > #include >> > > #include >> > > @@ -33,6 +34,8 @@ struct trace_eval_map { >> > >=20 >> > > #define TRACEPOINT_DEFAULT_PRIO 10 >> > >=20 >> > > +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(); >> > > } >> > >=20 >> > > @@ -129,18 +135,38 @@ extern void syscall_unregfunc(void); >> > > * as "(void *, void)"=2E The DECLARE_TRACE_NOARGS() will pass in >just >> > > * "void *data", where as the DECLARE_TRACE() will pass in "void >*data, proto"=2E >> > > */ >> > > -#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 =3D 0; \ >> > > \ >> > > if (!(cond)) \ >> > > return; \ >> > > - if (rcucheck) \ >> > > - rcu_irq_enter_irqson(); \ >> > > - rcu_read_lock_sched_notrace(); \ >> > > - it_func_ptr =3D rcu_dereference_sched((tp)->funcs); \ >> > > + \ >> > > + /* \ >> > > + * For rcuidle callers, use srcu since sched-rcu \ >> > > + * doesn't work from the idle path=2E \ >> > > + */ \ >> > > + if (rcuidle) { \ >> > > + if (in_nmi()) { \ >> > > + WARN_ON_ONCE(1); \ >> > > + return; /* no srcu from nmi */ \ >> > > + } \ >> > > + \ >> > > + idx =3D srcu_read_lock_notrace(&tracepoint_srcu); \ >> > > + it_func_ptr =3D \ >> > > + 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 =3D \ >> > > + rcu_dereference_sched((tp)->funcs); \ >> > > + } \ >> > > + \ >> > > if (it_func_ptr) { \ >> > > do { \ >> > > it_func =3D (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) { \ >> >=20 >> > Don't we also need an in_nmi() check here in order to avoid >unbalanced >> > srcu_read_unlock_notrace() calls? >>=20 >> The in_nmi() in the lock path should take care of making sure its >balanced=2E >>=20 >> The diff the way its formatted appears confusing as Mathieu pointed=2E > >Ah, right, I was for some reason thinking that the two hunks of the >diff were two separate macros=2E Apologies for my confusion! >=09 No worries! Thanks for the great idea to use in_nmi in the first place=2E - Joel > Thanx, Paul --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E