On 6/24/05, Xiangfei Jia <xjianz@xxxxxxxxx> wrote: > So, buddy allocator is used to solve external fragmentation. But itself has > internal fragmentation problem. Slab allocator is built on top of buddy > allocator, and solves the internal fragmentation caused by buddy allocator. > Is my undersanding right? > > I'm reading the book you mentationed. That's where I got confused. I have > read that part: there are two sets of caches, one for normal use, another > one for DMA. What I can't understand is how the slab allocator overcome the > internal fragmentation caused by buddy allocator. I am not a kernel expert, but I think I can answer in general based on my experience on malloc (user space memory allocator) and a few reading knowledge on kernel. I would like to understand more on kernel side. I think In buddy allocator there will be a minimum block size say for exmaple: 512 bytes. This much of memory will be allocated even when you request for example 10 bytes (assuming there is no slab allocator) . So other 502 bytes are wasted . But in case of slab alllocator over buddy, slab allocator requests for bigger block from the buddy and internalluy split the bigger block to definite number of fixed size. Always size would be aligned to boundary address. For example: 512 size of block from buddy will be divided in to 32 fragments of 16 bytes each. So when you request for 16 bytes, it would not go to buddy , but would be allocated from slab allocator and 16 bytes would be allocated and other fragments can be used to fullfill other requests ranging from 0-16 bytes. Considering our example of fullfilling request of 10 bytes, without slab allocator, internal fragmentation is 502 bytes, but with slab allocator, internal fragmentation is just 6 bytes. Hope this helps. Regards, Gopal. -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
