From patchwork Thu Aug 30 18:45:10 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Paul E. McKenney" X-Patchwork-Id: 11065 Return-Path: X-Original-To: patchwork@peony.canonical.com Delivered-To: patchwork@peony.canonical.com Received: from fiordland.canonical.com (fiordland.canonical.com [91.189.94.145]) by peony.canonical.com (Postfix) with ESMTP id E50A223E29 for ; Thu, 30 Aug 2012 18:45:57 +0000 (UTC) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by fiordland.canonical.com (Postfix) with ESMTP id A155DA184DD for ; Thu, 30 Aug 2012 18:45:21 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id k11so1016832iea.11 for ; Thu, 30 Aug 2012 11:45:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-forwarded-to:x-forwarded-for:delivered-to:received-spf:from:to:cc :subject:date:message-id:x-mailer:in-reply-to:references :x-content-scanned:x-cbid:x-gm-message-state; bh=qpu2yv2ulJgXMltsvBPUff6yHXQ6YGfrW2P1guF0hP4=; b=FXcfHVhizEHRvJR/X3AF1d6oA2rf72Fg8YLFmsNUqmZTpm0C/bvqlNJJNd1ElzylZe RY7US+C9DPrbQpusFkklS3R3MuvTyRW/GBd3g2KNqvoL3UyJ83ZUcs/tcjHZku41B/+E x0I3jHuaXKuJe1CGgJthNe77nv0tukv/DoxEy9nwWrsQZbdz4NNFk3eR/ulxqycNL3fP 8soRsFLN0Mn+QSSkQEI58DWPmrh7IL6NmwYbsqvXk94YuXHLzzlczd+2rgPE8rb3FROZ icOv2wJ0bYB/LP7iC0h0amaOa/9rBI5JpQrVUQAvTtou128DUmjxsP/i/mz8h9xfDWxc 21Cg== Received: by 10.50.7.212 with SMTP id l20mr1830854iga.43.1346352357403; Thu, 30 Aug 2012 11:45:57 -0700 (PDT) X-Forwarded-To: linaro-patchwork@canonical.com X-Forwarded-For: patch@linaro.org linaro-patchwork@canonical.com Delivered-To: patches@linaro.org Received: by 10.50.184.232 with SMTP id ex8csp25780igc; Thu, 30 Aug 2012 11:45:56 -0700 (PDT) Received: by 10.60.12.234 with SMTP id b10mr5852729oec.72.1346352356884; Thu, 30 Aug 2012 11:45:56 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com. [32.97.110.159]) by mx.google.com with ESMTPS id f7si3142058obd.190.2012.08.30.11.45.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2012 11:45:56 -0700 (PDT) Received-SPF: pass (google.com: domain of paulmck@linux.vnet.ibm.com designates 32.97.110.159 as permitted sender) client-ip=32.97.110.159; Authentication-Results: mx.google.com; spf=pass (google.com: domain of paulmck@linux.vnet.ibm.com designates 32.97.110.159 as permitted sender) smtp.mail=paulmck@linux.vnet.ibm.com Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 30 Aug 2012 12:45:56 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 30 Aug 2012 12:45:53 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 6BA233E4003E for ; Thu, 30 Aug 2012 12:45:51 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7UIjajn122666 for ; Thu, 30 Aug 2012 12:45:39 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q7UIjIEh016848 for ; Thu, 30 Aug 2012 12:45:19 -0600 Received: from paulmck-ThinkPad-W500 (sig-9-77-132-62.mts.ibm.com [9.77.132.62]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q7UIjHGQ016745; Thu, 30 Aug 2012 12:45:17 -0600 Received: by paulmck-ThinkPad-W500 (Postfix, from userid 1000) id C1FCFE523C; Thu, 30 Aug 2012 11:45:16 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org Cc: mingo@elte.hu, laijs@cn.fujitsu.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca, josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, Valdis.Kletnieks@vt.edu, dhowells@redhat.com, eric.dumazet@gmail.com, darren@dvhart.com, fweisbec@gmail.com, sbw@mit.edu, patches@linaro.org, "Paul E. McKenney" Subject: [PATCH tip/core/rcu 3/5] rcu: Document SRCU dead-CPU capabilities, emphasize read-side limits Date: Thu, 30 Aug 2012 11:45:10 -0700 Message-Id: <1346352312-31987-3-git-send-email-paulmck@linux.vnet.ibm.com> X-Mailer: git-send-email 1.7.8 In-Reply-To: <1346352312-31987-1-git-send-email-paulmck@linux.vnet.ibm.com> References: <20120830184448.GA31753@linux.vnet.ibm.com> <1346352312-31987-1-git-send-email-paulmck@linux.vnet.ibm.com> X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12083018-5518-0000-0000-00000739EE70 X-Gm-Message-State: ALoCoQnky6A1QwVIceJ0ZIfwoMa6v/KNOzObCw1okeOVM4O22pmgqMoIzrX+0O8yTbOBnWgyVtb9 From: "Paul E. McKenney" The current documentation did not help someone grepping for SRCU to learn that disabling preemption is not a replacement for srcu_read_lock(), so upgrade the documentation to bring this out, not just for SRCU, but also for RCU-bh. Also document the fact that SRCU readers are respected on CPUs executing in user mode, idle CPUs, and even on offline CPUs. Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett Reviewed-by: Lai Jiangshan --- Documentation/RCU/checklist.txt | 6 ++++++ Documentation/RCU/whatisRCU.txt | 9 +++++++-- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index fc103d7..cdb20d4 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -310,6 +310,12 @@ over a rather long period of time, but improvements are always welcome! code under the influence of preempt_disable(), you instead need to use synchronize_irq() or synchronize_sched(). + This same limitation also applies to synchronize_rcu_bh() + and synchronize_srcu(), as well as to the asynchronous and + expedited forms of the three primitives, namely call_rcu(), + call_rcu_bh(), call_srcu(), synchronize_rcu_expedited(), + synchronize_rcu_bh_expedited(), and synchronize_srcu_expedited(). + 12. Any lock acquired by an RCU callback must be acquired elsewhere with softirq disabled, e.g., via spin_lock_irqsave(), spin_lock_bh(), etc. Failing to disable irq on a given diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 69ee188..bf0f6de 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -873,7 +873,7 @@ d. Do you need to treat NMI handlers, hardirq handlers, and code segments with preemption disabled (whether via preempt_disable(), local_irq_save(), local_bh_disable(), or some other mechanism) as if they were explicit RCU readers? - If so, you need RCU-sched. + If so, RCU-sched is the only choice that will work for you. e. Do you need RCU grace periods to complete even in the face of softirq monopolization of one or more of the CPUs? For @@ -884,7 +884,12 @@ f. Is your workload too update-intensive for normal use of RCU, but inappropriate for other synchronization mechanisms? If so, consider SLAB_DESTROY_BY_RCU. But please be careful! -g. Otherwise, use RCU. +g. Do you need read-side critical sections that are respected + even though they are in the middle of the idle loop, during + user-mode execution, or on an offlined CPU? If so, SRCU is the + only choice that will work for you. + +h. Otherwise, use RCU. Of course, this all assumes that you have determined that RCU is in fact the right tool for your job.