lkml.org 
[lkml]   [2001]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] mempool-2.5.1-D2

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/

\
 
 \ /
  Last update: 2005-03-22 13:14    [from the cache]
©2003-2011 Jasper Spaans