From 0d539a6dae379685153866baa071780bbd389621 Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Mon, 25 Apr 2016 16:51:51 +0200 Subject: [PATCH] Remove wrong claims about the linux allocator (#147) --- posts/2016-04-11-kernel-heap.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/posts/2016-04-11-kernel-heap.md b/posts/2016-04-11-kernel-heap.md index 758355cb..01a9ae57 100644 --- a/posts/2016-04-11-kernel-heap.md +++ b/posts/2016-04-11-kernel-heap.md @@ -30,9 +30,7 @@ A good allocator is fast and reliable. It also effectively utilizes the availabl [fragmentation]: https://en.wikipedia.org/wiki/Fragmentation_(computing) [false sharing]: http://mechanical-sympathy.blogspot.de/2011/07/false-sharing.html -These requirements make good allocators pretty complex. For example, [jemalloc] has over 30.000 lines of code. This complexity is out of scope for most _kernel_ allocators. Even the Linux kernel uses a much simpler [buddy allocator] internally. Most of the complexity just isn't needed for kernel allocators, since kernels differ greatly from common applications. For example, kernels normally don't do heavy concurrent allocations. They allocate only when it's absolutely necessary. - -[buddy allocator]: https://en.wikipedia.org/wiki/Buddy_memory_allocation +These requirements make good allocators pretty complex. For example, [jemalloc] has over 30.000 lines of code. This complexity is out of scope for our kernel, so we will create a much simpler allocator. However, it should suffice for the foreseeable future, since we'll allocate only when it's absolutely necessary. ## A Bump Allocator