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

Update blog to 0d539a6dae

Browse Source
This commit is contained in:
travis-update-bot
2016-04-25 14:52:58 +00:00
parent c1f1121512
commit 298c9dc694
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) [fragmentation]: https://en.wikipedia.org/wiki/Fragmentation_(computing)
[false sharing]: http://mechanical-sympathy.blogspot.de/2011/07/false-sharing.html [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. 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.
[buddy allocator]: https://en.wikipedia.org/wiki/Buddy_memory_allocation
## A Bump Allocator ## A Bump Allocator