Messages in this thread | | | Date | Wed, 23 Mar 2005 22:46:45 +0100 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07 |
| |
* 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.
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. 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.
Ingo - 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/
| |