> 2) Why are there general caches up to a size of 128K byte? Since a > slab consists of physically contiguous pages, one might call right > into the buddy system to get chunks of memory that are a multiple of > a page size. What is the benefit of allocating memory chunks that are > a multiple of a page size by using kmalloc()/kmem_cache_alloc() > rather than get_free_pages? Not all of the genereal caches are bigger than a page. The sizes range from 64 bytes to 128k. The slab allocator is used to deal with smaller cache sizes, why have special case code for larger ones? Also, as you point out, there may be architectures with larger pages. (Even Intel i386 supports 4MB pages). > 3) How does the slab cache allocator deal with high memory pages in > 2.4.x (i.e. pages for which no KSEG address exists)? The comment at > the beginning of slab.c states, that a cache can support memory of > type GFP_HIGHMEM, however in kmem_cache_free_one() the > virt_to_page() macro is applied to the pointer to an object from the > slab - however this macro only works for KSEG (logical) addresses. > Why does the implementation still behave correctly, even if it uses > high memory (for which no KSEG addresses exist)? In spite of the comment in slab.c, the slab allocator does not use high memory pages. It uses pages from DMA and Normal zones only. Using highmem pages would mean looking for free kernel virtual addresses, probably in a reserved range (what vmalloc does). It may not be too hard to add this support, but there is not much gain either (I think..) Hope this helps, Ravi. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
