From patchwork Thu Aug 30 18:18:35 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: 11040 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 47FDD23EFE for ; Thu, 30 Aug 2012 18:19:05 +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 EC188A180C3 for ; Thu, 30 Aug 2012 18:18:28 +0000 (UTC) Received: by ieak11 with SMTP id k11so996735iea.11 for ; Thu, 30 Aug 2012 11:19:04 -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=RjW9L5tVyVLyl/HtdzwX4W5pB7aek2lLNheWKGTQwF4=; b=A1tUftZOYjUCNCE0O9/yxyOnB4Wk4PEzHHUcw+aZf/J1HQ6c02LJX03xxmZQvFlN1l VXNlkxzj9YcvMHNwWlk5UNhbA+tI1UpbZ+PHGZZp2rLBBU2PZDHWjG0hzljljXh/hkmz dKkcIYHe+RoVWcDeHeSR5fHAXxKZwc0q8Jv2ufgptBnnX+JWLk8pYrpCAPIsy9ckCmEr JoNWYhmRwV9GPWY3WgfpC/lHvV4KrMWefZetLc9O2qtUsVuBmifjl0z5CkyD0SeYEvOl iUf+bolipqzQpc6zVm/DmnA0bTsxSAJG0vNB9to0LrCokxi7hz9Q3uRGMHkthy0ULdIJ RagQ== Received: by 10.50.180.129 with SMTP id do1mr1799681igc.28.1346350744330; Thu, 30 Aug 2012 11:19:04 -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 ex8csp24689igc; Thu, 30 Aug 2012 11:19:04 -0700 (PDT) Received: by 10.60.22.196 with SMTP id g4mr5724157oef.95.1346350743874; Thu, 30 Aug 2012 11:19:03 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com. [32.97.182.139]) by mx.google.com with ESMTPS id f7si3062756obd.208.2012.08.30.11.19.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 30 Aug 2012 11:19:03 -0700 (PDT) Received-SPF: pass (google.com: domain of paulmck@linux.vnet.ibm.com designates 32.97.182.139 as permitted sender) client-ip=32.97.182.139; Authentication-Results: mx.google.com; spf=pass (google.com: domain of paulmck@linux.vnet.ibm.com designates 32.97.182.139 as permitted sender) smtp.mail=paulmck@linux.vnet.ibm.com Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 30 Aug 2012 14:19:02 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 30 Aug 2012 14:19:01 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id A88C96E803A for ; Thu, 30 Aug 2012 14:18:59 -0400 (EDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q7UIIwkr195720 for ; Thu, 30 Aug 2012 14:18:59 -0400 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 q7UIIiIh019097 for ; Thu, 30 Aug 2012 12:18:53 -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 q7UIIgD6018686; Thu, 30 Aug 2012 12:18:43 -0600 Received: by paulmck-ThinkPad-W500 (Postfix, from userid 1000) id 046FAEA83A; Thu, 30 Aug 2012 11:18:40 -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 20/23] rcu: Remove callback acceleration from grace-period initialization Date: Thu, 30 Aug 2012 11:18:35 -0700 Message-Id: <1346350718-30937-20-git-send-email-paulmck@linux.vnet.ibm.com> X-Mailer: git-send-email 1.7.8 In-Reply-To: <1346350718-30937-1-git-send-email-paulmck@linux.vnet.ibm.com> References: <20120830181811.GA29154@linux.vnet.ibm.com> <1346350718-30937-1-git-send-email-paulmck@linux.vnet.ibm.com> X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12083018-7182-0000-0000-000002742EC9 X-Gm-Message-State: ALoCoQmSdj0ywDRmlAc44r/Z3xe/D7bigKzOZlllQC0AsVGfKjibLNzna6M2eet8JY3kjhgqdw+7 From: "Paul E. McKenney" Before grace-period initialization was moved to a kthread, the CPU invoking this code would have at least one callback that needed a grace period, often a newly registered callback. However, moving grace-period initialization means that the CPU with the callback that was requesting a grace period is not necessarily the CPU that is initializing the grace period, so this acceleration is less valuable. Because it also adds to the complexity of reasoning about correctness, this commit removes it. Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- kernel/rcutree.c | 19 ------------------- 1 files changed, 0 insertions(+), 19 deletions(-) diff --git a/kernel/rcutree.c b/kernel/rcutree.c index 86903df..44609c3 100644 --- a/kernel/rcutree.c +++ b/kernel/rcutree.c @@ -1055,25 +1055,6 @@ static int rcu_gp_init(struct rcu_state *rsp) rsp->gpnum++; trace_rcu_grace_period(rsp->name, rsp->gpnum, "start"); record_gp_stall_check_time(rsp); - - /* - * Because this CPU just now started the new grace period, we - * know that all of its callbacks will be covered by this upcoming - * grace period, even the ones that were registered arbitrarily - * recently. Therefore, advance all RCU_NEXT_TAIL callbacks - * to RCU_NEXT_READY_TAIL. When the CPU later recognizes the - * start of the new grace period, it will advance all callbacks - * one position, which will cause all of its current outstanding - * callbacks to be handled by the newly started grace period. - * - * Other CPUs cannot be sure exactly when the grace period started. - * Therefore, their recently registered callbacks must pass through - * an additional RCU_NEXT_READY stage, so that they will be handled - * by the next RCU grace period. - */ - rdp = __this_cpu_ptr(rsp->rda); - rdp->nxttail[RCU_NEXT_READY_TAIL] = rdp->nxttail[RCU_NEXT_TAIL]; - raw_spin_unlock_irqrestore(&rnp->lock, flags); /* Exclude any concurrent CPU-hotplug operations. */