diff --git a/mps/design/cbs.txt b/mps/design/cbs.txt
index 226f971d56c..d130f3728de 100644
--- a/mps/design/cbs.txt
+++ b/mps/design/cbs.txt
@@ -251,9 +251,9 @@ if there is no suitable block.
 _`.impl.find-largest`: ``CBSFindLargest()`` simply finds out the size
 of the largest block in the CBS from the root of the tree, using
 ``SplayRoot()``, and does ``SplayFindFirst()`` for a block of that
-size. This is O(log *n*) in the size of the free list, so it's about
-the best you can do without maintaining a separate priority queue,
-just to do ``CBSFindLargest()``.
+size. This takes time proportional to the logarithm of the size of the
+free list, so it's about the best you can do without maintaining a
+separate priority queue, just to do ``CBSFindLargest()``.
 
 
 Low memory behaviour
diff --git a/mps/design/freelist.txt b/mps/design/freelist.txt
index c8e817edaea..a9c329e1ff3 100644
--- a/mps/design/freelist.txt
+++ b/mps/design/freelist.txt
@@ -29,7 +29,8 @@ situations, when memory is not available for the control structures
 needed by other allocators. In these situations the free list allocator
 ensures that memory is not lost, but with several disadvantages:
 
-1. operations on the free list are O(n) in the number of free blocks;
+1. operations on the free list take time proportional to the number of
+   free blocks;
 2. the data structures are stored in client memory and so are
    vulnerable to corruption;
 3. the data structures have poor locality (and thus potentially poor