For the btrfs extent cache it's unclear if just RCUing is a good
fit anyways: some workloads are very write heavy and RCU only
performs well if you have a lot more reads than writes.
For write heavy RCUification usually slows it down.
FWIW, I'm mentioning this out of self interest - I need a
Liu Bo liubo2...@cn.fujitsu.com writes:
Here we choose extent_map firstly, since it is a read mostly thing,
and the change is quite direct, all we need to do is
a) to replace rbtree with skiplist,
b) to add rcu support.
And more details are in patch 2 and patch 3.
I've done some simple
On 01/13/2012 05:28 AM, Andi Kleen wrote:
Liu Bo liubo2...@cn.fujitsu.com writes:
Here we choose extent_map firstly, since it is a read mostly thing,
and the change is quite direct, all we need to do is
a) to replace rbtree with skiplist,
b) to add rcu support.
And more details are in patch
On Fri, Jan 13, 2012 at 10:18:06AM +0800, Liu Bo wrote:
On 01/13/2012 05:28 AM, Andi Kleen wrote:
Liu Bo liubo2...@cn.fujitsu.com writes:
Here we choose extent_map firstly, since it is a read mostly thing,
and the change is quite direct, all we need to do is
a) to replace rbtree with
Since we are inclined to apply a lockless scheme on some objects of btrfs for
higher performance, we want to build a RCU version the Probabilistic Skiplist.
Here our skiplist algorithm is based on the skiplist experiments of
Con Kolivas ker...@kolivas.org for BFS cpu scheduler.
And more details
