From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: Ingo Molnar <mingo@elte.hu>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: [PATCH 2/2] rcupdate: use struct ref_completion
Date: Wed, 15 Apr 2009 11:18:54 +0800 [thread overview]
Message-ID: <49E5521E.5010105@cn.fujitsu.com> (raw)
Impact: Cleanup
The comment in _rcu_barrier() is a little mysterious,
this fix uses the generic waiting-multi-events APIs instead.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
index 2c7b845..82f1dc4 100644
--- a/kernel/rcupdate.c
+++ b/kernel/rcupdate.c
@@ -53,9 +53,8 @@ enum rcu_barrier {
};
static DEFINE_PER_CPU(struct rcu_head, rcu_barrier_head) = {NULL};
-static atomic_t rcu_barrier_cpu_count;
static DEFINE_MUTEX(rcu_barrier_mutex);
-static struct completion rcu_barrier_completion;
+static struct ref_completion rcu_barrier_completion;
int rcu_scheduler_active __read_mostly;
/*
@@ -96,8 +95,7 @@ EXPORT_SYMBOL_GPL(synchronize_rcu);
static void rcu_barrier_callback(struct rcu_head *notused)
{
- if (atomic_dec_and_test(&rcu_barrier_cpu_count))
- complete(&rcu_barrier_completion);
+ ref_completion_put(&rcu_barrier_completion);
}
/*
@@ -108,7 +106,7 @@ static void rcu_barrier_func(void *type)
int cpu = smp_processor_id();
struct rcu_head *head = &per_cpu(rcu_barrier_head, cpu);
- atomic_inc(&rcu_barrier_cpu_count);
+ ref_completion_get(&rcu_barrier_completion);
switch ((enum rcu_barrier)type) {
case RCU_BARRIER_STD:
call_rcu(head, rcu_barrier_callback);
@@ -133,21 +131,12 @@ static void _rcu_barrier(enum rcu_barrier type)
BUG_ON(in_interrupt());
/* Take cpucontrol mutex to protect against CPU hotplug */
mutex_lock(&rcu_barrier_mutex);
- init_completion(&rcu_barrier_completion);
- /*
- * Initialize rcu_barrier_cpu_count to 1, then invoke
- * rcu_barrier_func() on each CPU, so that each CPU also has
- * incremented rcu_barrier_cpu_count. Only then is it safe to
- * decrement rcu_barrier_cpu_count -- otherwise the first CPU
- * might complete its grace period before all of the other CPUs
- * did their increment, causing this function to return too
- * early.
- */
- atomic_set(&rcu_barrier_cpu_count, 1);
+
+ ref_completion_get_init(&rcu_barrier_completion);
on_each_cpu(rcu_barrier_func, (void *)type, 1);
- if (atomic_dec_and_test(&rcu_barrier_cpu_count))
- complete(&rcu_barrier_completion);
- wait_for_completion(&rcu_barrier_completion);
+ ref_completion_put_init(&rcu_barrier_completion);
+ ref_completion_wait(&rcu_barrier_completion);
+
mutex_unlock(&rcu_barrier_mutex);
wait_migrated_callbacks();
}
reply other threads:[~2009-04-15 3:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49E5521E.5010105@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox