Received: by 10.192.165.148 with SMTP id m20csp5006574imm; Tue, 1 May 2018 07:35:49 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr3VKYg6GVsXWceTLluB66HSyusVrj7t7k3xwmH5z4ghbgruKjH9R0bzr6OQ8pXH88ThXVN X-Received: by 2002:a63:ac56:: with SMTP id z22-v6mr13135491pgn.411.1525185349189; Tue, 01 May 2018 07:35:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525185349; cv=none; d=google.com; s=arc-20160816; b=tpWWQhlFWHWWSbXR2e4AIRc+FP8vaR+EsGpLADHBDi9N7tdwCSWWY7u7plXlK7YvgJ OjKYeztMLly6RbFnxUOf4sCmWtCZ3klA4pvQ/b5uVXSw8o+KUOttCZyXbuOZgq+NBIIu trEwhIKs4XqU+nbQRrDb7mBDAajt75+sJTe3qxWEcO6APFCpSQq9OZtsVDcc4irt7KwV GxBB3XUbCl+6w/+gZuIIRZ9k38vEp12FwSXINcxcPVDEfkmnaCUCnZpIHmO4jQecnKb+ +FAL4Kap6ANWzheLGxMfv9Tg4IoWseOTI0latBeXAjkPltJhI0/zjrVkwe2zi1YjZ2dV PIWg== 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=c2MdcHXD0qvs2YZD1TTAb/CSwUGwvBWpJypGQeBIHd0=; b=jf3q6D8c9aKTnyH+zo7JFTV8PdZyJF4bPsA9zRAHbHtDCltMXLK0phIfxBKIBxkekP 6NyF5KAemstsKLoZfA8hGYfny//ye24qTeaw4FhsyG/oSMflqdquOumGvvuTfbm0hpOH svhK6fHBDehLHaIZPfOaLTFFcypQyHBq6zKHFscG7dtSGQNo/65Vp7gKU4Y4cTJ2v8AY x6i7woaoXA8RigwxQhCgxCukcpuk+e3Cdrv/fzG8UxiW48RGc3HcO0NAN37Wwxao57eu mNFddeV7fGJ2iLg9FfrghQQ8KYSvqPDoP8pmFGST6Mx4403Xk+Y33WyzFvTuW3Qa/K61 9SRA== 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 x4-v6si7710144pgt.575.2018.05.01.07.35.34; Tue, 01 May 2018 07:35:49 -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 S1756033AbeEAOeu (ORCPT + 99 others); Tue, 1 May 2018 10:34:50 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57022 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755876AbeEAOes (ORCPT ); Tue, 1 May 2018 10:34:48 -0400 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w41EYJAt057887 for ; Tue, 1 May 2018 10:34:47 -0400 Received: from e12.ny.us.ibm.com (e12.ny.us.ibm.com [129.33.205.202]) by mx0b-001b2d01.pphosted.com with ESMTP id 2hpsfxsmem-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 01 May 2018 10:34:47 -0400 Received: from localhost by e12.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 1 May 2018 10:34:46 -0400 Received: from b01cxnp22036.gho.pok.ibm.com (9.57.198.26) by e12.ny.us.ibm.com (146.89.104.199) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 1 May 2018 10:34:42 -0400 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w41EYflM54198474; Tue, 1 May 2018 14:34:41 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 77405B2052; Tue, 1 May 2018 11:36:42 -0400 (EDT) Received: from paulmck-ThinkPad-W541 (unknown [9.70.82.108]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP id 24770B2046; Tue, 1 May 2018 11:36:42 -0400 (EDT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id AA00816C0E9F; Tue, 1 May 2018 07:36:01 -0700 (PDT) Date: Tue, 1 May 2018 07:36:01 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: Joel Fernandes , linux-kernel@vger.kernel.org, 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 v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU Reply-To: paulmck@linux.vnet.ibm.com References: <20180501014204.67548-1-joelaf@google.com> <20180501014204.67548-6-joelaf@google.com> <20180501102401.2cac5781@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180501102401.2cac5781@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18050114-0048-0000-0000-00000266829C X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008957; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000257; SDB=6.01025967; UDB=6.00523957; IPR=6.00805198; MB=3.00020882; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-01 14:34:46 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18050114-0049-0000-0000-000044F78B9C Message-Id: <20180501143601.GG26088@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-01_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805010146 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 01, 2018 at 10:24:01AM -0400, Steven Rostedt wrote: > On Mon, 30 Apr 2018 18:42:03 -0700 > Joel Fernandes wrote: > > > 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. [ . . . ] > > --- a/kernel/tracepoint.c > > +++ b/kernel/tracepoint.c > > @@ -31,6 +31,9 @@ > > extern struct tracepoint * const __start___tracepoints_ptrs[]; > > extern struct tracepoint * const __stop___tracepoints_ptrs[]; > > > > +DEFINE_SRCU(tracepoint_srcu); > > +EXPORT_SYMBOL_GPL(tracepoint_srcu); > > + > > /* Set to 1 to enable tracepoint debug output */ > > static const int tracepoint_debug; > > > > @@ -67,11 +70,16 @@ static inline void *allocate_probes(int count) > > return p == NULL ? NULL : p->probes; > > } > > > > -static void rcu_free_old_probes(struct rcu_head *head) > > +static void srcu_free_old_probes(struct rcu_head *head) > > { > > kfree(container_of(head, struct tp_probes, rcu)); > > } > > > > +static void rcu_free_old_probes(struct rcu_head *head) > > +{ > > + call_srcu(&tracepoint_srcu, head, srcu_free_old_probes); > > Hmm, is it OK to call call_srcu() from a call_rcu() callback? I guess > it would be. It is perfectly legal, and quite a bit simpler than setting something up to wait for both to complete concurrently. Of course, if you unconditionally call call_srcu() from that same srcu_struct's callback, SRCU will be unable to safely delete the srcu_struct, so cleanup_srcu_struct() will react by leaking memory. ;-) Normal RCU deals with the analogous situation by leaving at least one callback uninvoked when the system goes down. Thanx, Paul > I think we should add a comment to why we are doing this. Something > like: > > /* > * Tracepoint probes are protected by both sched RCU and SRCU, by > * calling the SRCU callback in the sched RCU callback we cover > * both cases. > */ > > Or something along those lines. > > -- Steve > > > > +} > > + > > static inline void release_probes(struct tracepoint_func *old) > > { > > if (old) { >