-----Original Message----- From: Andev [mailto:debiandev@gmail.com] Sent: Friday, April 10, 2015 1:13 PM To: Jeff Haran Cc: kernelnewbies Subject: Re: maybe dumb question about RCU
On Fri, Apr 10, 2015 at 12:47 PM, Jeff Haran <Jeff.Haran@citrix.com> wrote:
The msleep() happens after the rcu_assign_pointer()/synchronize_rcu()
sequence, not in the middle of it. All that msleep() is for is to make sure the updater isn't spinning that core and I chose the value so that the updater which thus runs every 1.5 seconds doesn't beat with the reader that is holding the rcu read lock for 1 second. Now one can argue that this in the reader is an atypically long time to hold a RCU read lock:
rcu_read_lock(); a = rcu_dereference(rcu_pointer); start = get_jiffies_64(); while (get_jiffies_64() < (start + 1000)); b = rcu_dereference(rcu_pointer); rcu_read_unlock();
That causes the RCU read "lock" to be held for 1 second (at least on
systems where a jiffie is a millisecond). But if that's "too long" then how long exactly is "too long"? If 1 second is too long, is 1 millisecond too long? How is the developer using this interface to know either how long is too long or how long the code they've written will take to execute given the plethora of different systems it might run on?
The documentation I've seen says that the only restriction on RCU readers
is that they don't block and the above doesn't so it satisfies the requirements of the interface near as I can tell.
This section of the code might still be pre-empted. Try putting a preempt_disable() at the beginning and see if you are getting the same value or not.
Relevant comment here: http://lxr.free-electrons.com/source/include/linux/rcupdate.h#L837
When you say "at the beginning", where do you mean? Right before the rcu_read_lock()? And I assume a preempt_enable() should be in there too? Where would that go? Though, it doesn't seem like this should make any difference. Disabling preemption would keep other processes from running on the core the reader is on, but the writing via rcu_assign_pointer() could (and probably is) happening on another core. Thanks, Jeff Haran