summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKent Overstreet <kent.overstreet@gmail.com>2015-07-17 19:23:54 -0700
committerKent Overstreet <kent.overstreet@gmail.com>2015-07-17 19:23:54 -0700
commitcf974fbe204ac7f190fa1a024a762b4450e9d08c (patch)
tree04fbc164a96d543ed8fe2eef2136adaaceee2e76
parentdfeaedf583f5d71d5eb43fb401f7946b016a10a8 (diff)
todo
-rw-r--r--Todo.mdwn23
1 files changed, 12 insertions, 11 deletions
diff --git a/Todo.mdwn b/Todo.mdwn
index e6d2d72..e5c286d 100644
--- a/Todo.mdwn
+++ b/Todo.mdwn
@@ -1,16 +1,17 @@
bcache/bcachefs todo list:
- * Asynchronous btree node splits
-
- The last source of tail latency in the index update path is btree node
- splits/compacts - a btree node split has to write out the new node(s) and
- then update the parent node, all synchronously.
-
- This is particularly painful with bcachefs, as we end up doing a lot more
- index updates (dirents/inodes/xattrs) as a proportion of total IO.
-
- Need to get the design for this written down. Slava and I had it worked out,
- but we didn't write anything down so we'll have to go over it again.
+ * Implement epochs, and get rid of read retry path
+
+ The idea is a refcount on allocator cycles - "epochs" - if something (e.g.
+ copygc) is buffering extents where GC can't find them (for recalculating the
+ oldest gen), it can take a ref on the current epoch; current epoch - oldest
+ existing epoch = how much more out of date pointer gens can be, for keys gc
+ can't find - then the allocator can wait if this is too big.
+
+ For foreground reads, the trick is the read takes a (percpu) refcount on the
+ current epoch, and releases it when the read completes; then when the
+ allocator wants to start another cycle, it bumps the epoch, then waits for
+ all the references from foreground reads to go to 0 on the previous epoch.
* Lockless btree lookups