Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp959849imm; Wed, 8 Aug 2018 08:28:56 -0700 (PDT) X-Google-Smtp-Source: AA+uWPyobAGMOojivrmTZ2UH8Wjh47NCWm/U/gixut8tkwyA/FzSaNPSVtafm/0AXjv55VofBK30 X-Received: by 2002:a62:5e45:: with SMTP id s66-v6mr3484382pfb.129.1533742136065; Wed, 08 Aug 2018 08:28:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533742136; cv=none; d=google.com; s=arc-20160816; b=ZQOV67yh2GSzM5HOHyi9BWWgmQG39rGDpLmsUZwXnyt1fgog808tVVKAuuaQYuDsMy q+ROrOA8OCZHB3aT8mdmkR3whYoo47SdlTEKU+V59zUphSPnosUGl1fKxweCUnbnHiWb i2dPrKTx1ZqJvRy6wUpA1N1ItmHKds5JOXn6RYvvuRLocvbldxohL15p4YtSUUtsIQCc P+c5MkzxKYpqtu/HvuG/8rqYLxGewISnqw9Q3zqLVQWXDcSUrcUYWeeoorz1MSVT3Nlt sFl+4Dk6G2dL11yH3TrIS7XY6H/32fC1PGHZmNMUr92oGHqjqa70nnEFAbHpgkdHPh3H lrLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=LmP28lZoLCIxyJhlcIfWF4nHQgkTWQR0AGuRLsrKFyg=; b=iy7Dn9vv4JSyY6a5MD35yId6lJQ3psFBZCfT8ad2dUK5QGgzC+VdQos2Fw1PZ8CwbK Khkqe3fRG30JgMCj5nodUiibag0GnIYS4eZHprIYChX6rXWPMT9Hi4eji8/4yLCYn2a6 J+cUt3sWtSqL+oRH6KOJ1xrDvMMwiCCyeFWJz0opLXbBVlJ7c5/gqVzE/O2LoosYMqSp rO5lD6w5ZqRxlCXXp0+8YqXykrXg6OxeiA2i7hVMuaR27mPMasvM0NdrTskHoxSXPQwn xE0ORr5RCBS8KxUEgtODfiDO8/XnLQ55ez8SQLESBIVXBl7A6Erdys6k9LWqD4ihWZE+ CuRw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i10-v6si4325573pgk.203.2018.08.08.08.28.40; Wed, 08 Aug 2018 08:28:56 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727431AbeHHRrS (ORCPT + 99 others); Wed, 8 Aug 2018 13:47:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:55854 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727069AbeHHRrS (ORCPT ); Wed, 8 Aug 2018 13:47:18 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 545E721990; Wed, 8 Aug 2018 15:27:07 +0000 (UTC) Date: Wed, 8 Aug 2018 11:27:05 -0400 From: Steven Rostedt To: "Paul E. McKenney" Cc: Joel Fernandes , Joel Fernandes , LKML , "Cc: Android Kernel" , Boqun Feng , Byungchul Park , Ingo Molnar , Masami Hiramatsu , Mathieu Desnoyers , Namhyung Kim , Peter Zijlstra , Thomas Glexiner , Tom Zanussi Subject: Re: [PATCH v12 3/3] tracing: Centralize preemptirq tracepoints and unify their usage Message-ID: <20180808112705.22e6a96d@gandalf.local.home> In-Reply-To: <20180808144200.GM24813@linux.vnet.ibm.com> References: <6D0A3FD6-2190-4CC0-A3C0-7B3759E73243@google.com> <20180807204820.50b83c6d@vmware.local.home> <20180807215522.04114097@vmware.local.home> <20180807222856.3ede96e7@vmware.local.home> <20180808130041.GI24813@linux.vnet.ibm.com> <20180808102700.38c4169d@gandalf.local.home> <20180808144200.GM24813@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 Aug 2018 07:42:00 -0700 "Paul E. McKenney" wrote: > > There's also a local_inc() if you are using per cpu pointers, that is > > suppose to guarantee atomicity for single cpu operations. That's what > > the ftrace ring buffer uses. > > Good point, that becomes atomic_long_inc() or equivalent on most > architectures, but an incl instruction (not locked) on x86. So updating > my earlier still-untested thought: > > int __srcu_read_lock_nmi(struct srcu_struct *sp) /* UNTESTED. */ > { > int idx; > > idx = READ_ONCE(sp->srcu_idx) & 0x1; > local_inc(&sp->sda->srcu_lock_count[idx]); > smp_mb__after_atomic(); /* B */ /* Avoid leaking critical section. */ > return idx; > } > > void __srcu_read_unlock_nmi(struct srcu_struct *sp, int idx) > { > smp_mb__before_atomic(); /* C */ /* Avoid leaking critical section. */ > local_inc(&sp->sda->srcu_unlock_count[idx]); > } > > Would that work, or is there a better way to handle this? This would work much better than using the atomic ops, and I think it would be doable. I may need to revert the srcu for trace_*_rcidle() for now, as I want most of the other changes in this merge window, and it's getting too late to do it with these updates. -- Steve