Re: Kmem_cache handling in linux-2.6.2x kernel

["Pekka Enberg" <penberg@cs.helsinki.fi>]

Hi,

On Wed, Jul 9, 2008 at 1:30 PM,  <KokHow.Teh@infineon.com> 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.

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@infineon.com> 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@infineon.com> 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(). 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()).