summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKent Overstreet <kent.overstreet@gmail.com>2021-04-11 20:00:23 -0400
committerKent Overstreet <kent.overstreet@gmail.com>2021-04-11 20:00:23 -0400
commitca5107a90dd49b640c922e2f72bf032447b1ac28 (patch)
treed7b3e93e333aea679663429bdcf2c57e7a8d96c8
parent0c82c32ab1a66329d56337c183db3e8397e06025 (diff)
fix typos
-rw-r--r--Roadmap.mdwn4
1 files changed, 2 insertions, 2 deletions
diff --git a/Roadmap.mdwn b/Roadmap.mdwn
index b61cc9a..13e4442 100644
--- a/Roadmap.mdwn
+++ b/Roadmap.mdwn
@@ -34,7 +34,7 @@ even when our memery accesses are not cached.
On my Ryzen 3900X single threaded lookups across 16M keys go at 1.3M second, and
scale almost linearly - with 12 threads it's about 12M/second. We can do 16M
random inserts at 670k per second single threaded; with 12 threads we achieve
-2.4 random inserts per second.
+2.4M random inserts per second.
Btree locking is very well optimized. We have external btree iterators which
make it easy to aggressively drop and retake locks, giving the filesystem as a
@@ -57,7 +57,7 @@ where we're losing performance.
Filesystem metadata operation performance (e.g. fsmark): On most benchmarks, we
seem to be approaching or sometimes mathing XFS on performance. There are
-exceptions: multithreaded rm -rf of empty files is currently roughly 4k slower
+exceptions: multithreaded rm -rf of empty files is currently roughly 4x slower
than XFS - we bottleneck on journal reclaim, which is flushing inodes from the
btree key cache back to the inodes btree.