On Mon, Mar 02, 2015 at 09:23:45AM +0100, Peter Zijlstra wrote:
> It changes the rb-tree from using internal storage like we do now, to
> requiring external storage.
Note that one consequence of using external storage is that tree
iteration will always require two cachelines per level. One to
load
On Sun, Mar 01, 2015 at 01:52:09PM +, Mathieu Desnoyers wrote:
> > 2) there must not be (temporary) loops in the tree structure in the
> > modifier's program order, this would cause a lookup which
> > interrupts the modifier to get stuck indefinitely.
>
> For (2), I don't think this i
On Sun, Mar 01, 2015 at 01:11:23PM -0800, Michel Lespinasse wrote:
> On Sat, Feb 28, 2015 at 1:24 PM, Peter Zijlstra wrote:
> > It generates slightly worse code, probably because gcc stinks at
> > volatile. But in pointer chasing heavy code a few instructions more
> > should not matter.
>
> So,
* Michel Lespinasse wrote:
> On Sat, Feb 28, 2015 at 1:24 PM, Peter Zijlstra wrote:
> > Change the insert and erase code such that lockless searches are
> > non-fatal.
> >
> > In and of itself an rbtree cannot be correctly searched while
> > in-modification, we can however provide weaker guaran
On Sat, Feb 28, 2015 at 1:24 PM, Peter Zijlstra wrote:
> Change the insert and erase code such that lockless searches are
> non-fatal.
>
> In and of itself an rbtree cannot be correctly searched while
> in-modification, we can however provide weaker guarantees that will
> allow the rbtree to be us
..@linutronix.de, pet...@infradead.org,
> "Michel Lespinasse" , "Andrea Arcangeli"
> , "David Woodhouse"
> , "Rik van Riel"
> Sent: Saturday, February 28, 2015 4:24:52 PM
> Subject: [RFC][PATCH 5/9] rbtree: Make lockless searches non-fatal
>
Change the insert and erase code such that lockless searches are
non-fatal.
In and of itself an rbtree cannot be correctly searched while
in-modification, we can however provide weaker guarantees that will
allow the rbtree to be used in conjunction with other techniques, such
as latches; see 9b0fd
7 matches
Mail list logo
