From ae96835b94bce7aa889cae6231f900dc9e48a4b3 Mon Sep 17 00:00:00 2001 From: Daniel Micay Date: Mon, 4 Feb 2019 15:59:14 -0500 Subject: [PATCH] fix scalability header levels --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 5cbe509..a10eb29 100644 --- a/README.md +++ b/README.md @@ -406,7 +406,7 @@ allocation size classes may be offered as an option in the future. ## Scalability -## Small (slab) allocations +### Small (slab) allocations As a baseline form of fine-grained locking, the slab allocator has entirely separate allocators for each size class. Each size class has a dedicated lock, @@ -441,7 +441,7 @@ attempt to use heuristics for dynamically tuning the size, but there's not a great one size fits all approach so it isn't currently part of this allocator implementation. -### Thread caching (or lack thereof) +#### Thread caching (or lack thereof) Thread caches are a commonly implemented optimization in modern allocators but aren't very suitable for a hardened allocator even when implemented via arrays @@ -480,7 +480,7 @@ and it's entirely unsuitable / incompatible with a hardened allocator since it bypasses all of the underlying security and would destroy much of the security value. -## Large allocations +### Large allocations The expectation is that the allocator does not need to perform well for large allocations, especially in terms of scalability. When the performance for large