public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: axboe@kernel.dk, akinobu.mita@gmail.com, tom.leiming@gmail.com
Cc: kent.overstreet@gmail.com, cl@linux-foundation.org,
	linux-kernel@vger.kernel.org, kernel-team@fb.com,
	Tejun Heo <tj@kernel.org>
Subject: [PATCH 1/5] percpu_ref: remove unnecessary RCU grace period for staggered atomic switching confirmation
Date: Tue, 29 Sep 2015 17:47:16 -0400	[thread overview]
Message-ID: <1443563240-29306-2-git-send-email-tj@kernel.org> (raw)
In-Reply-To: <1443563240-29306-1-git-send-email-tj@kernel.org>

At the beginning, percpu_ref guaranteed a RCU grace period between a
call to percpu_ref_kill_and_confirm() and the invocation of the
confirmation callback.  This guarantee exposed internal implementation
details and got rescinded while switching over to sched RCU; however,
__percpu_ref_switch_to_atomic() still inserts a full sched RCU grace
period even when it can simply wait for the previous attempt.

Remove the unnecessary grace period and perform the confirmation
synchronously for staggered atomic switching attempts.  Update
comments accordingly.

Signed-off-by: Tejun Heo <tj@kernel.org>
---
 lib/percpu-refcount.c | 22 ++++------------------
 1 file changed, 4 insertions(+), 18 deletions(-)

diff --git a/lib/percpu-refcount.c b/lib/percpu-refcount.c
index 6111bcb..95f3c13 100644
--- a/lib/percpu-refcount.c
+++ b/lib/percpu-refcount.c
@@ -177,17 +177,11 @@ static void __percpu_ref_switch_to_atomic(struct percpu_ref *ref,
 		call_rcu_sched(&ref->rcu, percpu_ref_switch_to_atomic_rcu);
 	} else if (confirm_switch) {
 		/*
-		 * Somebody already set ATOMIC.  Switching may still be in
-		 * progress.  @confirm_switch must be invoked after the
-		 * switching is complete and a full sched RCU grace period
-		 * has passed.  Wait synchronously for the previous
-		 * switching and schedule @confirm_switch invocation.
+		 * Somebody else already set ATOMIC.  Wait for its
+		 * completion and invoke @confirm_switch() directly.
 		 */
 		wait_event(percpu_ref_switch_waitq, !ref->confirm_switch);
-		ref->confirm_switch = confirm_switch;
-
-		percpu_ref_get(ref);	/* put after confirmation */
-		call_rcu_sched(&ref->rcu, percpu_ref_call_confirm_rcu);
+		confirm_switch(ref);
 	}
 }
 
@@ -211,10 +205,6 @@ static void __percpu_ref_switch_to_atomic(struct percpu_ref *ref,
  * but it may block if @confirm_kill is specified and @ref is already in
  * the process of switching to atomic mode.  In such cases, @confirm_switch
  * will be invoked after the switching is complete.
- *
- * Due to the way percpu_ref is implemented, @confirm_switch will be called
- * after at least one full sched RCU grace period has passed but this is an
- * implementation detail and must not be depended upon.
  */
 void percpu_ref_switch_to_atomic(struct percpu_ref *ref,
 				 percpu_ref_func_t *confirm_switch)
@@ -290,11 +280,7 @@ void percpu_ref_switch_to_percpu(struct percpu_ref *ref)
  *
  * This function normally doesn't block and can be called from any context
  * but it may block if @confirm_kill is specified and @ref is in the
- * process of switching to atomic mode by percpu_ref_switch_atomic().
- *
- * Due to the way percpu_ref is implemented, @confirm_switch will be called
- * after at least one full sched RCU grace period has passed but this is an
- * implementation detail and must not be depended upon.
+ * process of switching to atomic mode by percpu_ref_switch_to_atomic().
  */
 void percpu_ref_kill_and_confirm(struct percpu_ref *ref,
 				 percpu_ref_func_t *confirm_kill)
-- 
2.4.3


  reply	other threads:[~2015-09-29 21:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-29 21:47 [PATCHSET percpu/for-4.4] percpu_ref: make mode switching operations synchronize themselves Tejun Heo
2015-09-29 21:47 ` Tejun Heo [this message]
2015-09-29 21:47 ` [PATCH 2/5] percpu_ref: reorganize __percpu_ref_switch_to_atomic() and relocate percpu_ref_switch_to_atomic() Tejun Heo
2015-09-29 21:47 ` [PATCH 3/5] percpu_ref: unify staggered atomic switching wait behavior Tejun Heo
2015-09-29 21:47 ` [PATCH 4/5] percpu_ref: restructure operation mode switching Tejun Heo
2015-09-29 21:47 ` [PATCH 5/5] percpu_ref: allow operation mode switching operations to be called concurrently Tejun Heo
2016-08-10 19:06 ` [PATCHSET percpu/for-4.4] percpu_ref: make mode switching operations synchronize themselves Tejun Heo

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=1443563240-29306-2-git-send-email-tj@kernel.org \
    --to=tj@kernel.org \
    --cc=akinobu.mita@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=cl@linux-foundation.org \
    --cc=kent.overstreet@gmail.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tom.leiming@gmail.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