From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752778AbeDXRZz (ORCPT ); Tue, 24 Apr 2018 13:25:55 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:43152 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751420AbeDXRZw (ORCPT ); Tue, 24 Apr 2018 13:25:52 -0400 Date: Tue, 24 Apr 2018 10:26:58 -0700 From: "Paul E. McKenney" To: Joel Fernandes Cc: Steven Rostedt , Mathieu Desnoyers , Namhyung Kim , Masami Hiramatsu , linux-kernel , linux-rt-users , Peter Zijlstra , Ingo Molnar , Tom Zanussi , Thomas Gleixner , Boqun Feng , fweisbec , Randy Dunlap , kbuild test robot , baohong liu , vedang patel , kernel-team Subject: Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you can Reply-To: paulmck@linux.vnet.ibm.com References: <20180423031926.GF26088@linux.vnet.ibm.com> <409016827.14587.1524493888181.JavaMail.zimbra@efficios.com> <20180423105325.7d5d245b@gandalf.local.home> <1045420715.14686.1524495583859.JavaMail.zimbra@efficios.com> <20180423121800.47b173af@gandalf.local.home> <1212130312.14753.1524503541789.JavaMail.zimbra@efficios.com> <20180423172244.694dbc9d@gandalf.local.home> <20180424155655.GA820@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18042417-0036-0000-0000-000002E9807E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008914; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000257; SDB=6.01022665; UDB=6.00521999; IPR=6.00801899; MB=3.00020752; MTD=3.00000008; XFM=3.00000015; UTC=2018-04-24 17:25:48 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18042417-0037-0000-0000-00004419AD9D Message-Id: <20180424172658.GT26088@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-24_04:,, 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-1804240166 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 24, 2018 at 09:01:34AM -0700, Joel Fernandes wrote: > On Tue, Apr 24, 2018 at 8:56 AM, Paul E. McKenney > wrote: > > On Mon, Apr 23, 2018 at 05:22:44PM -0400, Steven Rostedt wrote: > >> On Mon, 23 Apr 2018 13:12:21 -0400 (EDT) > >> Mathieu Desnoyers wrote: > >> > >> > >> > I'm inclined to explicitly declare the tracepoints with their given > >> > synchronization method. Tracepoint probe callback functions for currently > >> > existing tracepoints expect to have preemption disabled when invoked. > >> > This assumption will not be true anymore for srcu-tracepoints. > >> > >> Actually, why not have a flag attached to the tracepoint_func that > >> states if it expects preemption to be enabled or not? If a > >> trace_##event##_srcu() is called, then simply disable preemption before > >> calling the callbacks for it. That way if a callback is fine for use > >> with srcu, then it would require calling > >> > >> register_trace_##event##_may_sleep(); > >> > >> Then if someone uses this on a tracepoint where preemption is disabled, > >> we simply do not call it. > > > > One more stupid question... If we are having to trace so much stuff > > in the idle loop, are we perhaps grossly overstating the extent of that > > "idle" loop? For being called "idle", this code seems quite busy! > > ;-) > The performance hit I am observing is when running a heavy workload, > like hackbench or something like that. That's what I am trying to > correct. > By the way is there any limitation on using SRCU too early during > boot? I backported Mathieu's srcu tracepoint patches but the kernel > hangs pretty early in the boot. I register lockdep probes in > start_kernel. I am hoping that's not why. > > I could also have just screwed up the backporting... may be for my > testing, I will just replace the rcu API with the srcu instead of all > of Mathieu's new TRACE_EVENT macros for SRCU, since all I am trying to > do right now is measure the performance of my patches with SRCU. Gah, yes, there is an entry on my capacious todo list on making SRCU grace periods work during early boot and mid-boot. Let me see what I can do... Thanx, Paul