On Fri, 14 Dec 2001, Benjamin LaHaise wrote:
> Btw, wouldn't reservation result in the same effect as these mempools
> for significantly less code?
exactly what kind of SLAB based reservation system do you have in mind?
(what interface, how would it work, etc.) Take a look at how bio.c,
highmem.c and raid1.c uses the mempool mechanizm, the main properties of
mempool cannot be expressed via SLAB reservation:
- mempool allows the use of non-SLAB allocators as the underlying
allocator. (eg. the highmem.c mempool uses the page allocator to alloc
lowmem pages. raid1.c uses 4 allocators: kmalloc(), page_alloc(),
bio_alloc() and mempool_alloc() of a different pool.)
- mempool_alloc(), if called from a process context, never fails. This
simplifies lowlevel IO code (which often must not fail) visibly.
- mempool allows the pooling of arbitrarily complex memory buffers, not
just a single SLAB buffer. (eg. the raid1.c resync pool uses a
combination of alloc_mempool(), bio_alloc() and multiple page_alloc()
buffers. This is also a performance enhancement for raid1.c.)
- mempool handles allocation in a more deadlock-avoidance-aware way than
a normal allocator would do:
- first it ->alloc()'s atomically
- then it tries to take from the pool if the pool is at least
half full
- then it ->alloc()'s non-atomically
- then it takes from the pool if it's non-empty
- then it waits for pool elements to be freed
this makes for five different levels of allocation, ordered for
performance and blocking-avoidance, while still kicking the VM and
trying as hard as possible if there is a resource squeeze. In the
normal case we never touch the mempool spinlocks, we just call
->alloc() and if the core allocator does per-CPU caching then we'll
have the exact same high level of scalability as the underlying
allocator.
- mempool adds reservation without increasing the complexity of the
underlying allocators.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 15 2001 - 21:00:29 EST