michaelkuc6/blog_os
1
0
Fork 0
mirror of https://github.com/phil-opp/blog_os.git synced 2025-12-16 14:27:49 +00:00
Code Issues Projects Releases Wiki Activity

Remove wrong claims about the linux allocator (#147)

Browse Source
This commit is contained in:
Philipp Oppermann
2016-04-25 16:51:51 +02:00
parent 9e74969732
commit 0d539a6dae
1 changed files with 1 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
posts/2016-04-11-kernel-heap.md
View File

@@ -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