linux-kernel - RE: Kmem_cache handling in linux-2.6.2x kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <31E09F73562D7A4D82119D7F6C172986046C717D@sinse303.ap.infineon.com>
Date:	Wed, 9 Jul 2008 19:23:42 +0800
From:	<KokHow.Teh@...ineon.com>
To:	<penberg@...helsinki.fi>
Cc:	<linux-kernel@...r.kernel.org>, <cl@...ux-foundation.org>
Subject: RE: Kmem_cache handling in linux-2.6.2x kernel

Hi; 

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

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

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/