From 4b8c902354aab48d3ef93357a3d8423bba95957e Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Mon, 27 Jan 2020 12:46:33 +0100 Subject: [PATCH] Fix typo --- blog/content/second-edition/posts/11-allocator-designs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/blog/content/second-edition/posts/11-allocator-designs/index.md b/blog/content/second-edition/posts/11-allocator-designs/index.md index 65bc094e3..1c241ea8a 100644 --- a/blog/content/second-edition/posts/11-allocator-designs/index.md +++ b/blog/content/second-edition/posts/11-allocator-designs/index.md @@ -37,7 +37,7 @@ Apart from correctness, there are many secondary design goals. For example, the [_fragmentation_]: https://en.wikipedia.org/wiki/Fragmentation_(computing) [false sharing]: http://mechanical-sympathy.blogspot.de/2011/07/false-sharing.html -These requirements can make good allocators very complex. For example, [jemalloc] has over 30.000 lines of code. This complexity often undesired in kernel code where a single bug can lead to severe security vulnerabilities. Fortunately, the allocation patterns of kernel code are often much simpler compared to userspace code, so that relatively simple allocator designs often suffice. +These requirements can make good allocators very complex. For example, [jemalloc] has over 30.000 lines of code. This complexity is often undesired in kernel code where a single bug can lead to severe security vulnerabilities. Fortunately, the allocation patterns of kernel code are often much simpler compared to userspace code, so that relatively simple allocator designs often suffice. [jemalloc]: http://jemalloc.net/