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
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
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,
On Sun, Mar 01, 2015 at 01:11:23PM -0800, Michel Lespinasse wrote:
On Sat, Feb 28, 2015 at 1:24 PM, Peter Zijlstra pet...@infradead.org wrote:
It generates slightly worse code, probably because gcc stinks at
volatile. But in pointer chasing heavy code a few instructions more
should not
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 is how
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
* 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
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
..@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 searche
On Sat, Feb 28, 2015 at 1:24 PM, Peter Zijlstra pet...@infradead.org 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
...@linutronix.de, pet...@infradead.org,
Michel Lespinasse wal...@google.com, Andrea Arcangeli
aarca...@redhat.com, David Woodhouse
david.woodho...@intel.com, Rik van Riel r...@redhat.com
Sent: Saturday, February 28, 2015 4:24:52 PM
Subject: [RFC][PATCH 5/9] rbtree: Make lockless searches non
* Michel Lespinasse wal...@google.com wrote:
On Sat, Feb 28, 2015 at 1:24 PM, Peter Zijlstra pet...@infradead.org 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
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
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
14 matches
Mail list logo
