On Fri, Oct 15, 2004 at 07:12:26 +1000, Aboo Valappil wrote: > > I'am aware that kmalloc() should be used for smaller > > sizes , but would it not be a huge waste & be a cause > > of internal fragmentation if vmalloc() were to > > allocate 4MB pages ? > > Vmalloc() allocates 4KB pages only, that is the minimum size and it > could only allocate in multiple of 4K. Vmalloc area is above > ZONE_NORMAL. > > While kmalloc() returns an address inside ZONE_NORMAL and the size of > the allocated area is nothing to do with the page size. Does any one > have a different opition on this ? I have never looked at the details. From what I know there is a basic allocation mechanizm, get_free_pages. This obtains physicaly consecutive ranges of pages from the underlying buddy allocator. Vmalloc is a wrapper above this, that is able to remap the pages if it can't get continuous block. Kmalloc is a simplified interface to a more general slab cache allocator. The slab cache allocator -- kmem_cache_alloc -- gets pages from the buddy allocator (via get_free_pages) and partitions them up to chunks of requested size. Each cache contains chunks of some specified size. Kmalloc itself allocates from generic kmem_caches. These come in all powers of two from 32B to 128KB (I may be off by one). Kmalloc finds closest larger cache to the request and allocates from there. Allocation is best done via kmem_cache. It is both fastest and causes least fragmentation and it has added value of constructor and destructor. These allow to have partialy initialized data structures in kmem_cache -- if you know that when a structure is released, some fields have initial values (eg. locks, refcounts...), they don't have to be reinitialized. Depending on the structure quite a lot can be saved. Then for allocations up to a page, kmalloc is appropriate if the requested blocks vary in size. For larger sizes, vmalloc becomes prefered, since it can remap the pages, so it will work even if the memory is too fragmented for high-order allocation to succeed from gfp. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
