2011/10/2 Lev Serebryakov <[email protected]>: > Hello, Freebsd-hackers. > > Here are several memory-allocation mechanisms in the kernel. The two > I'm aware of is MALLOC_DEFINE()/malloc()/free() and uma_* (zone(9)). > > As far as I understand, malloc() is general-purpose, but it has > fixed "transaction cost" (in term of memory consumption) for each > block allocated, and is not very suitable for allocation of many small > blocks, as lots of memory will be wasted for bookkeeping. > > zone(9) allocator, on other hand, have very low cost of each > allocated block, but could allocate only pre-configured fixed-size > blocks, and ideal for allocation tons of small objects (and provide > API for reusing them, too!). > > Am I right? > > But what if I need to allocate a lot (say, 16K-32K) of page-sized > blocks? Not in one chunk, for sure, but in lifetime of my kernel > module. Which allocator should I use? It seems, the best one will be > very low-level only-page-sized allocator. Is here any in kernel? > > -- > // Black Lion AKA Lev Serebryakov <[email protected]> > > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[email protected]" >
My 2cents: Everytime you request a certain amount of memory bigger than 4KB using kernel malloc(), it results in a direct call to uma_large_malloc(). Right now, uma_large_malloc() calls kmem_malloc() (i.e. the memory is requested to the VM directly). This kind of approach has two main drawbacks: 1) it heavily fragments the kernel heap 2) when free() is called on these multipage chunks, it in turn calls uma_large_free(), which immediately calls the VM system to unmap and free the chunk of memory. The unmapping requires a system-wide TLB shootdown, i.e. a global action by every processor in the system. I'm currently working supervised by alc@ to an intermediate layer that sits between UMA and the VM, which goal is satisfyinh efficiently requests > 4KB (so, the one you want considering you're asking for 16KB-32KB), but the work is in an early stage. Best, Davide _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
