Messages in this thread | | | Date | Mon, 28 Dec 2009 08:28:39 +0530 | From | Balbir Singh <> | Subject | Re: [RFC PATCH] asynchronous page fault. |
| |
* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-12-28 10:05:14]:
> On Mon, 28 Dec 2009 06:27:46 +0530 > Balbir Singh <balbir@linux.vnet.ibm.com> wrote: > > > * Peter Zijlstra <peterz@infradead.org> [2009-12-27 12:19:56]: > > > > > Your changelog states as much. > > > > > > "Even if RB-tree rotation occurs while we walk tree for look-up, we just > > > miss vma without oops." > > > > > > However, since this is the case, do we still need the > > > rcu_assign_pointer() conversion your patch does? All I can see it do is > > > slow down all RB-tree users, without any gain. > > > > Don't we need the rcu_assign_pointer() on the read side primarily to > > make sure the pointer is still valid and assignments (writes) are not > > re-ordered? Are you suggesting that the pointer assignment paths be > > completely atomic? > > > >From following reasons. > - What we have to avoid is not to touch unkonwn memory via broken pointer. > This is speculative look up and can miss vmas. So, even if tree is broken, > there is no problem. Broken pointer which points to places other than rb-tree > is problem.
Exactly!
> - rb-tree's rb_left and rb_right don't points to memory other than > rb-tree. (or NULL) And vmas are not freed/reused while rcu_read_lock(). > Then, we don't dive into unknown memory. > - Then, we can skip rcu_assign_pointer(). >
We can, but the data being on read-side is going to be out-of-date more than without the use of rcu_assign_pointer(). Do we need variants like to rcu_rb_next() to avoid overheads for everyone?
-- Balbir
| |