From patchwork Wed Feb 22 09:29:28 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lai Jiangshan X-Patchwork-Id: 6873 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 2BC8A23EAE for ; Wed, 22 Feb 2012 09:25:07 +0000 (UTC) Received: from mail-iy0-f180.google.com (mail-iy0-f180.google.com [209.85.210.180]) by fiordland.canonical.com (Postfix) with ESMTP id C2757A186B8 for ; Wed, 22 Feb 2012 09:25:06 +0000 (UTC) Received: by iabz7 with SMTP id z7so14128999iab.11 for ; Wed, 22 Feb 2012 01:25:06 -0800 (PST) Received: from mr.google.com ([10.50.135.37]) by 10.50.135.37 with SMTP id pp5mr25213405igb.26.1329902706263 (num_hops = 1); Wed, 22 Feb 2012 01:25:06 -0800 (PST) Received: by 10.50.135.37 with SMTP id pp5mr20335529igb.26.1329902706193; Wed, 22 Feb 2012 01:25:06 -0800 (PST) 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.231.11.10 with SMTP id r10csp129381ibr; Wed, 22 Feb 2012 01:25:05 -0800 (PST) Received: by 10.43.134.199 with SMTP id id7mr24858576icc.21.1329902704958; Wed, 22 Feb 2012 01:25:04 -0800 (PST) Received: from song.cn.fujitsu.com ([222.73.24.84]) by mx.google.com with ESMTP id r8si19398119icq.102.2012.02.22.01.25.02; Wed, 22 Feb 2012 01:25:04 -0800 (PST) Received-SPF: neutral (google.com: 222.73.24.84 is neither permitted nor denied by best guess record for domain of laijs@cn.fujitsu.com) client-ip=222.73.24.84; Authentication-Results: mx.google.com; spf=neutral (google.com: 222.73.24.84 is neither permitted nor denied by best guess record for domain of laijs@cn.fujitsu.com) smtp.mail=laijs@cn.fujitsu.com Received: from tang.cn.fujitsu.com (tang.cn.fujitsu.com [10.167.250.3]) by song.cn.fujitsu.com (Postfix) with ESMTP id D01D717015D; Wed, 22 Feb 2012 17:25:00 +0800 (CST) Received: from mailserver.fnst.cn.fujitsu.com (tang.cn.fujitsu.com [127.0.0.1]) by tang.cn.fujitsu.com (8.14.3/8.13.1) with ESMTP id q1M9OwPR030305; Wed, 22 Feb 2012 17:24:59 +0800 Received: from lai.fc14.fnst ([10.167.225.146]) by mailserver.fnst.cn.fujitsu.com (Lotus Domino Release 8.5.1FP4) with ESMTP id 2012022217231757-733183 ; Wed, 22 Feb 2012 17:23:17 +0800 Message-ID: <4F44B578.4030007@cn.fujitsu.com> Date: Wed, 22 Feb 2012 17:29:28 +0800 From: Lai Jiangshan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc14 Thunderbird/3.1.4 MIME-Version: 1.0 To: paulmck@linux.vnet.ibm.com CC: linux-kernel@vger.kernel.org, mingo@elte.hu, 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, patches@linaro.org Subject: [PATCH 1/3 RFC paul/rcu/srcu] srcu: Remove fast check path References: <20120213020951.GA12138@linux.vnet.ibm.com> <4F41F315.1040900@cn.fujitsu.com> <20120220174418.GI2470@linux.vnet.ibm.com> <4F42EF53.6060400@cn.fujitsu.com> <20120221015037.GE2384@linux.vnet.ibm.com> <4F435966.9020106@cn.fujitsu.com> <20120221172442.GG2375@linux.vnet.ibm.com> In-Reply-To: <20120221172442.GG2375@linux.vnet.ibm.com> X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2012-02-22 17:23:17, Serialize by Router on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2012-02-22 17:23:19, Serialize complete at 2012-02-22 17:23:19 X-Gm-Message-State: ALoCoQmRumBK1W4PJ9I3ZXQZhngkISGs/4dpDlmpaWH/VvCvuBybhO06EUnnMU7RJzBqEcQ3R9/a Hi, All These three patches reduce the states of srcu. the call_srcu() will be implemented based on this new algorithm if it has no problem. It is an aggressive algorithm, it needs more reviews, please examine it critically and leave your comments. Thanks, Lai. >From abe3fd64d08f74f13e8111e333a9790e9e6d782c Mon Sep 17 00:00:00 2001 From: Lai Jiangshan Date: Wed, 22 Feb 2012 10:15:48 +0800 Subject: [PATCH 1/3 RFC paul/rcu/srcu] srcu: Remove fast check path This fast check path is used for optimizing the situation that there are many concurrently update site. But we have no suck situation in currect kernel. And it introduces complexity, so we just remove it. Signed-off-by: Lai Jiangshan --- kernel/srcu.c | 25 +------------------------ 1 files changed, 1 insertions(+), 24 deletions(-) diff --git a/kernel/srcu.c b/kernel/srcu.c index 84c9b97..17e95bc 100644 --- a/kernel/srcu.c +++ b/kernel/srcu.c @@ -308,7 +308,7 @@ static void flip_idx_and_wait(struct srcu_struct *sp, bool expedited) */ static void __synchronize_srcu(struct srcu_struct *sp, bool expedited) { - int idx; + int idx = 0; rcu_lockdep_assert(!lock_is_held(&sp->dep_map) && !lock_is_held(&rcu_bh_lock_map) && @@ -316,32 +316,9 @@ static void __synchronize_srcu(struct srcu_struct *sp, bool expedited) !lock_is_held(&rcu_sched_lock_map), "Illegal synchronize_srcu() in same-type SRCU (or RCU) read-side critical section"); - smp_mb(); /* Ensure prior action happens before grace period. */ - idx = ACCESS_ONCE(sp->completed); - smp_mb(); /* Access to ->completed before lock acquisition. */ mutex_lock(&sp->mutex); /* - * Check to see if someone else did the work for us while we were - * waiting to acquire the lock. We need -three- advances of - * the counter, not just one. If there was but one, we might have - * shown up -after- our helper's first synchronize_sched(), thus - * having failed to prevent CPU-reordering races with concurrent - * srcu_read_unlock()s on other CPUs (see comment below). If there - * was only two, we are guaranteed to have waited through only one - * full index-flip phase. So we either (1) wait for three or - * (2) supply the additional ones we need. - */ - - if (sp->completed == idx + 2) - idx = 1; - else if (sp->completed == idx + 3) { - mutex_unlock(&sp->mutex); - return; - } else - idx = 0; - - /* * If there were no helpers, then we need to do two flips of * the index. The first flip is required if there are any * outstanding SRCU readers even if there are no new readers