patternMinor
Buddy system allocator and slab allocator in Linux kernel
Viewed 0 times
buddysystemslablinuxandkernelallocator
Problem
In the Silberschatz's book "operating systems" the author talks about the allocation of memory via system buddy and slab.
My first question is: in the book, both memory allocation methods are described as allocation method that the kernel use to allocate memory only for kernel's process, not for user's process. Is it true?
My second question, as the title suggest, regards the allocation method that is implemented inside the Linux kernel. Looking the website kernel.org I've seen that there is a chapter dedicated to buddy system and a page dedicated to slab. So, I imagine that both are present inside the kernel, but what is one method for and what is the other for?
My first question is: in the book, both memory allocation methods are described as allocation method that the kernel use to allocate memory only for kernel's process, not for user's process. Is it true?
My second question, as the title suggest, regards the allocation method that is implemented inside the Linux kernel. Looking the website kernel.org I've seen that there is a chapter dedicated to buddy system and a page dedicated to slab. So, I imagine that both are present inside the kernel, but what is one method for and what is the other for?
Solution
A modern operating system manages physical memory as page frames. A page frame can be allocated to a user process or for the kernel to use for its own purposes, such as to allocate its own data structures.
A kernel data object (e.g. a structure representing an "open file" or something) is typically less than the size of a page. So it makes sense to have a two-level allocation hierarchy: one to manage page frames, and one to allocate data structures inside allocated page frames.
Linux uses a buddy allocator to allocate page frames, and a slab allocator to allocate kernel data structures. When the slab allocator needs more memory, it obtains it from the buddy allocator.
This approach works well for Linux, since it supports different page sizes; x86-64 CPUs support 4kB, 2M, and sometimes 2GB pages, and a binary buddy allocator can support this with very little modification.
Windows NT, by comparison, uses a simple free list to implement page frame allocation. Actually, that's not quite accurate; it uses multiple free lists to implement cache colouring, but that's a story for another time. Again, it layers another allocator on top to handle kernel data structures.
It's a similar story with Mach, the microkernel underneath macOS and iOS. Kernel data structures are implemented with a zone allocator, which plays the same role as the slab allocator in Linux. It, again, operates as a layer above the physical page frame allocator.
A kernel data object (e.g. a structure representing an "open file" or something) is typically less than the size of a page. So it makes sense to have a two-level allocation hierarchy: one to manage page frames, and one to allocate data structures inside allocated page frames.
Linux uses a buddy allocator to allocate page frames, and a slab allocator to allocate kernel data structures. When the slab allocator needs more memory, it obtains it from the buddy allocator.
This approach works well for Linux, since it supports different page sizes; x86-64 CPUs support 4kB, 2M, and sometimes 2GB pages, and a binary buddy allocator can support this with very little modification.
Windows NT, by comparison, uses a simple free list to implement page frame allocation. Actually, that's not quite accurate; it uses multiple free lists to implement cache colouring, but that's a story for another time. Again, it layers another allocator on top to handle kernel data structures.
It's a similar story with Mach, the microkernel underneath macOS and iOS. Kernel data structures are implemented with a zone allocator, which plays the same role as the slab allocator in Linux. It, again, operates as a layer above the physical page frame allocator.
Context
StackExchange Computer Science Q#152260, answer score: 4
Revisions (0)
No revisions yet.