[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130616215546.GB28587@htj.dyndns.org>
Date: Sun, 16 Jun 2013 14:55:46 -0700
From: Tejun Heo <tj@...nel.org>
To: Kent Overstreet <koverstreet@...gle.com>
Cc: Michal Hocko <mhocko@...e.cz>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Rusty Russell <rusty@...tcorp.com.au>,
linux-kernel@...r.kernel.org
Subject: [PATCH percpu/for-3.11] percpu-refcount: use RCU-sched insted of
normal RCU
percpu-refcount was incorrectly using preempt_disable/enable() for RCU
critical sections against call_rcu(). 6a24474da8 ("percpu-refcount:
consistently use plain (non-sched) RCU") fixed it by converting the
preepmtion operations with rcu_read_[un]lock() citing that there isn't
any advantage in using sched-RCU over using the usual one; however,
rcu_read_[un]lock() for the preemptible RCU implementation -
CONFIG_TREE_PREEMPT_RCU, chosen when CONFIG_PREEMPT - are slightly
more expensive than preempt_disable/enable().
In a contrived microbench which repeats the followings,
- percpu_ref_get()
- copy 32 bytes of data into percpu buffer
- percpu_put_get()
- copy 32 bytes of data into percpu buffer
rcu_read_[un]lock() used in percpu_ref_get/put() makes it go slower by
about 15% when compared to using sched-RCU.
As the RCU critical sections are extremely short, using sched-RCU
shouldn't have any latency implications. Convert to RCU-sched.
Signed-off-by: Tejun Heo <tj@...nel.org>
Cc: Kent Overstreet <koverstreet@...gle.com>
Cc: Michal Hocko <mhocko@...e.cz>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Rusty Russell <rusty@...tcorp.com.au>
---
include/linux/percpu-refcount.h | 12 ++++++------
lib/percpu-refcount.c | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -105,7 +105,7 @@ static inline void percpu_ref_get(struct
{
unsigned __percpu *pcpu_count;
- rcu_read_lock();
+ rcu_read_lock_sched();
pcpu_count = ACCESS_ONCE(ref->pcpu_count);
@@ -114,7 +114,7 @@ static inline void percpu_ref_get(struct
else
atomic_inc(&ref->count);
- rcu_read_unlock();
+ rcu_read_unlock_sched();
}
/**
@@ -134,7 +134,7 @@ static inline bool percpu_ref_tryget(str
unsigned __percpu *pcpu_count;
int ret = false;
- rcu_read_lock();
+ rcu_read_lock_sched();
pcpu_count = ACCESS_ONCE(ref->pcpu_count);
@@ -143,7 +143,7 @@ static inline bool percpu_ref_tryget(str
ret = true;
}
- rcu_read_unlock();
+ rcu_read_unlock_sched();
return ret;
}
@@ -159,7 +159,7 @@ static inline void percpu_ref_put(struct
{
unsigned __percpu *pcpu_count;
- rcu_read_lock();
+ rcu_read_lock_sched();
pcpu_count = ACCESS_ONCE(ref->pcpu_count);
@@ -168,7 +168,7 @@ static inline void percpu_ref_put(struct
else if (unlikely(atomic_dec_and_test(&ref->count)))
ref->release(ref);
- rcu_read_unlock();
+ rcu_read_unlock_sched();
}
#endif
--- a/lib/percpu-refcount.c
+++ b/lib/percpu-refcount.c
@@ -154,5 +154,5 @@ void percpu_ref_kill_and_confirm(struct
(((unsigned long) ref->pcpu_count)|PCPU_REF_DEAD);
ref->confirm_kill = confirm_kill;
- call_rcu(&ref->rcu, percpu_ref_kill_rcu);
+ call_rcu_sched(&ref->rcu, percpu_ref_kill_rcu);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists