linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Manfred Spraul <manfred@dbl.q-ag.de>
To: linux-kernel@vger.kernel.org, lse-tech@lists.sourceforge.net
Subject: [RFC, PATCH] 4/5 rcu lock update: Hide locking details
Date: Tue, 25 May 2004 07:35:23 +0200	[thread overview]
Message-ID: <200405250535.i4P5ZN6g017615@dbl.q-ag.de> (raw)

Hi,

Step four for reducing cacheline trashing within rcupdate.c,
second step for a hierarchical cpumask bitmap: 

Move the locking calls that protect rcu_cpu_mask into cpu_quiet.

What do you think?

--
	Manfred

// $Header$
// Kernel Version:
//  VERSION = 2
//  PATCHLEVEL = 6
//  SUBLEVEL = 6
//  EXTRAVERSION = -mm4
--- 2.6/kernel/rcupdate.c	2004-05-23 11:57:48.000000000 +0200
+++ build-2.6/kernel/rcupdate.c	2004-05-23 11:56:32.000000000 +0200
@@ -153,14 +153,27 @@
  * Clear it from the cpu mask and complete the grace period if it was the last
  * cpu. Start another grace period if someone has further entries pending
  */
-static void cpu_quiet(int cpu)
+static void cpu_quiet(int cpu, int force)
 {
+	spin_lock(&rcu_state.mutex);
+
+	if (unlikely(rcu_ctrlblk.completed == rcu_ctrlblk.cur))
+		goto out_unlock;
+	/*
+	 * RCU_quiescbatch/batch.cur and the cpu bitmap can come out of sync
+	 * during cpu startup. Ignore the quiescent state.
+	 */
+	if (unlikely(RCU_quiescbatch(cpu) != rcu_ctrlblk.cur) && likely(!force))
+       		goto out_unlock;
+
 	cpu_clear(cpu, rcu_state.rcu_cpu_mask);
 	if (cpus_empty(rcu_state.rcu_cpu_mask)) {
 		/* batch completed ! */
 		rcu_ctrlblk.completed = rcu_ctrlblk.cur;
 		rcu_start_batch(0);
 	}
+out_unlock:
+	spin_unlock(&rcu_state.mutex);
 }
 
 /*
@@ -196,15 +209,8 @@
 		return;
 	RCU_qs_pending(cpu) = 0;
 
-	spin_lock(&rcu_state.mutex);
-	/*
-	 * RCU_quiescbatch/batch.cur and the cpu bitmap can come out of sync
-	 * during cpu startup. Ignore the quiescent state.
-	 */
-	if (likely(RCU_quiescbatch(cpu) == rcu_ctrlblk.cur)) 
-		cpu_quiet(cpu);
+	cpu_quiet(cpu, 0);
 
-	spin_unlock(&rcu_state.mutex);
 }
 
 
@@ -234,11 +240,7 @@
 	 * we can block indefinitely waiting for it, so flush
 	 * it here
 	 */
-	spin_lock_bh(&rcu_state.mutex);
-	if (rcu_ctrlblk.cur != rcu_ctrlblk.completed)
-		cpu_quiet(cpu);
-unlock:
-	spin_unlock_bh(&rcu_state.mutex);
+	cpu_quiet(cpu, 1);
 
 	rcu_move_batch(&RCU_curlist(cpu));
 	rcu_move_batch(&RCU_nxtlist(cpu));

                 reply	other threads:[~2004-05-25  5:35 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=200405250535.i4P5ZN6g017615@dbl.q-ag.de \
    --to=manfred@dbl.q-ag.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    /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;
as well as URLs for NNTP newsgroup(s).