RE: Kmem_cache handling in linux-2.6.2x kernel

[KokHow.Teh]

Hi; 

>On Wed, Jul 9, 2008 at 1:30 PM,  <KokHow.Teh@xxxxxxxxxxxx> wrote:
>> In my applications, only part of total number of objects of the 
>> kmem_cache are freed. So my question is what happen to these "freed"
>> objects? How are these "freed" objects managed by the linux-MM? Would

>> they be reused by other kmem_cache_alloc() and/or kmalloc()?

>The free'd objects will be returned to the cache and are, of course,
reused by later kmem_cache_alloc() and kmalloc() calls. 
>Note that with _SLAB_, you never have cache sharing, so an object
free'd by kmem_cache_free() is only available for a kmem_cache_alloc()
of the same cache.

So with _SLAB_, kmem_cache_free() objects are only reusuable by
kmem_cache_alloc() of the same cache.

Are kmem_cache_free() objects reusable by _all_ kmalloc() calls? (*)

>At some point in time, I wrote:
>>>In addition, SLUB does slab merging so the same cache can be  
>>>transparently used by other kmem_cache_alloc() callers. So there 
>>>really  are no reservation guarantees for a cache in OOM conditions.

>On Wed, Jul 9, 2008 at 1:30 PM,  <KokHow.Teh@xxxxxxxxxxxx> wrote:
>> (1) SLUB is not available in 2.6.20 kernel which I am using for my 
>> products. In this case, is there similar mechamisms in place to 
>> faciliate "page-sharing" amongst the kmem_cache_alloc() callers?

>No.

>On Wed, Jul 9, 2008 at 1:30 PM,  <KokHow.Teh@xxxxxxxxxxxx> wrote:
>> (2) Does this "page-sharing" happen for kmalloc() callers?

>The caches for kmalloc() are set up first, so a kmalloc() never dips
into a cache created by kmem_cache_create(). 

This conflicts with (*) above.

>But a kmem_cache_alloc() can dip into a kmalloc cache. Look at the
create_kmalloc_cache() calls in kmem_cache_init() and the
find_mergeable() call in
>kmem_cache_create() in mm/slub.c for details.

>Btw, you mentioned that you're allocating 64 KBs. So with SLUB, if you
use _kmalloc()_ the request will be passed through to the page allocator
directly (see kmalloc_large()).

What's your point here? How would this compare to using the kmem_cache?

Thanks.

Regards,
KH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/