Messages in this thread | | | Date | Wed, 23 Mar 2005 22:59:41 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07 |
| |
On Wed, Mar 23, 2005 at 10:46:45PM +0100, Ingo Molnar wrote: > > * Ingo Molnar <mingo@elte.hu> wrote: > > > i think the 'migrate read-count' method is not adequate either, > > because all callbacks queued within an RCU read section must be called > > after the lock has been dropped - while with the migration method > > CPU#1 would be free to process callbacks queued in the RCU read > > section still active on CPU#2. > > > > i'm wondering how much of a problem this is though. Can there be stale > > pointers at that point? Yes in theory, because code like: > > > > rcu_read_lock(); > > call_rcu(&dentry->d_rcu, d_callback); > > func(dentry->whatever); > > rcu_read_unlock(); > > but, this cannot happen, because call_rcu() is used by RCU-write code.
The code would not look exactly like this, but acquiring the update-side lock inside an RCU read-side critical section can be thought of as a reader-to-writer lock upgrade. RCU can do this unconditionally, which was one of the walls I was banging my head against when trying to think up a realtime-safe RCU implementation.
So something like the following would be legitimate RCU code:
rcu_read_lock(); spin_lock(&dcache_lock); call_rcu(&dentry->d_rcu, d_callback); spin_unlock(&dcache_lock); rcu_read_unlock();
The spin_lock() call upgrades from a read-side to a write-side critical section.
> so the important property seems to be that any active RCU-read section > should keep at least one CPU's active_readers count elevated > permanently, for the duration of the RCU-read section.
Yep!
> It doesnt matter > that the reader migrates between CPUs - because the RCU code itself > guarantees that no callbacks will be executed until _all_ CPUs have been > in quiescent state. I.e. all CPUs have to go through a zero > active_readers value before the callback is done.
Yep again!
Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |