linux-kernel - Re: A question on RCU vs. preempt-RCU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 16 Jun 2013 14:40:28 -0700
From:	Tejun Heo <tj@...nel.org>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>,
	Kent Overstreet <koverstreet@...gle.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: A question on RCU vs. preempt-RCU

Hello, Paul.

On Sun, Jun 16, 2013 at 07:13:35AM -0700, Paul E. McKenney wrote:
> CONFIG_TREE_PREEMPT_RCU does have an increment, decrement (sort of),
> and check in its rcu_read_lock() and rcu_read_unlock(), which will
> add overhead that might well be noticeable compared to CONFIG_TREE_RCU's
> zero-code implementation of rcu_read_lock() and rcu_read_unlock().

Yeah, I should have added one more data point.  I was testing atomic_t
vs. percpu-ref and saw the overhead and worrying that it would show
regression against preempt_disable/enable() implementation.

Just ran some tests and preempt_disable/enable() based implementation
is about 18% faster than rcu_read_lock/unlock() based one.

Compared to atomic_t, in a horribly contrived test case, normal RCU
would be slower by around 20% while the preemption one would be slower
by 7.5%.

> The main source of longer latency from preempt_disable/enable()
> (or rcu_read_{,un}lock_sched()) will be on the read side.
> The callback-processing is very nearly identical.

Ah, right.  I was completely confused there.  The goal of
CONFIG_TREE_PREEMPT_RCU is to allow preemption inside RCU read
critical sections.  I knew that at one point and completely forgot
about it, so using preemption based one is fine as long as the length
of critical section is short.

> The big question is "how long are the RCU read-side critical sections?"

Extremely short.  It's gonna be like five instructions.

> My guess is that module references can have arbitrarily long lifetimes,

Preemption is disabled only while the refcnt operations are actually
going on.

> which would argue strongly against use of RCU-sched.  But if the lifetimes
> are always short (say, sub-microsecond), then RCU-sched should be fine.

So, RCU-sched, it is.

Thanks a lot for the help!

-- 
tejun
--
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/