From: Tejun Heo <tj@kernel.org>
To: Kent Overstreet <koverstreet@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH percpu/for-3.11] percpu-refcount: use RCU-sched insted of normal RCU
Date: Sun, 16 Jun 2013 16:13:03 -0700 [thread overview]
Message-ID: <20130616231303.GE28587@htj.dyndns.org> (raw)
In-Reply-To: <20130616215546.GB28587@htj.dyndns.org>
On Sun, Jun 16, 2013 at 02:55:46PM -0700, Tejun Heo wrote:
> 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@kernel.org>
> Cc: Kent Overstreet <koverstreet@google.com>
> Cc: Michal Hocko <mhocko@suse.cz>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
Applied to percpu/for-3.11 with acks added. Thanks!
--
tejun
prev parent reply other threads:[~2013-06-16 23:13 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-16 21:55 [PATCH percpu/for-3.11] percpu-refcount: use RCU-sched insted of normal RCU Tejun Heo
2013-06-16 23:04 ` Paul E. McKenney
2013-06-16 23:10 ` Kent Overstreet
2013-06-16 23:13 ` Tejun Heo [this message]
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=20130616231303.GE28587@htj.dyndns.org \
--to=tj@kernel.org \
--cc=koverstreet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rusty@rustcorp.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.