[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1261989173.7135.5.camel@laptop>
Date: Mon, 28 Dec 2009 09:32:53 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: balbir@...ux.vnet.ibm.com
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"minchan.kim@...il.com" <minchan.kim@...il.com>,
cl@...ux-foundation.org
Subject: Re: [RFC PATCH] asynchronous page fault.
On Mon, 2009-12-28 at 06:27 +0530, Balbir Singh wrote:
> * Peter Zijlstra <peterz@...radead.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?
rcu_assign_pointer() is the write side, but if you need a barrier, you
can make do with a single smp_wmb() after doing the rb-tree op. There is
no need to add multiple in the tree-ops themselves.
You cannot make the assignment paths atomic (without locks) that's the
whole problem.
--
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/
Powered by blists - more mailing lists